The age old problem which repeats itself is, how to make a single code base for a project which is delivered to multiple platforms?!
Many tachnologies has come and promised the same thing. The end result is to enter the corporate space. Why!? Money.
This is the true story of all the technology stacks which promise to have a single codebase. Some really nice technologies has come and stayed for good, some vanished without leaving a trace.
For a software service provider it is not a problem though. As they get paid to do it over and over again. But for a product perspective, it is worse.
Technology
From the technology side, it is not always money though. There are some brilliant solutions happened. These things really solved the problem at hand, but it never really is a place to stay like that.
- It is either too focused to present problems
- Or it is too general purpose to be solving all the problems
Too focused
If it is too focused it solved a very focused problem and solved it well to cater to all the platforms. But, once the technology industry moved on, these solutions could never solve it again for the new technologies. To keep up with the new tech-stack and provide the same solution boiled down to provide similar solution. Slowly as the time goes on, these focused solutions could not provide the solution at all for current time. People / Teams which were too excited to jump into these solutions are now stuck.
They either has to accept their mistake and move on to new solutions or leave the team and join another team.
In both the cases the product suffers. The management simply pushed the agenda that we built a crossplatform single code solution and now other people simply could not stand to our standards! The beginning of an endless hire and fire or employed and searching phase starts. The product goes from an example of, how things should be done for a single code crossplatform solution to how one should not code a product.
Too general
If it is too general purpose solution, the adaption is very minimal and focused teams needed to solve the problem. The maintainance of such products will not be a problem as long as people work in these technologies.
At first it gives an impression of extrawork. In the long run it is nice provided the team sticks together.
However the point is, it is extra work and there comes a time, when some new solution provides it out of the box. Team solwly thinks they should move on and can not do it, mostly because can not accept their own mistake.
UX and UI
This is probably the reason why no solution could be just one code base. Every platform has its own UX. And the product has to decide whether to
- Have same UX for all the platforms
- Have UX design as per the platforms
Both are possible and depends upon which solution is taken. Some of the very nice products are designed as the UX is driven by the product. So no matter what platform, once a user is inside the product, it feels home. This requires more work on UX, does not mean it is visible in the product. There might be a possibility that there is very minimal UI but best UX. So the research is more here. Mostly the typical solution is design the UX as per the platform. There are some nice products here also. But then these products just adapt to the new UX as soon as the platform updates. So the iteration rate is too high and too fast.
In both these scenarios, single code base is nightmare to maintain even for a small time.
If the UX is driven by the product, there is some chance of single code base, but then the design of UI might be so much into the product that one has to write everything for the product from scratch.
If the UX is driven by the platform, then keeping up to the platform and solution will be a drag.
New approach is to learn once
This atleast is a much better approach. Actually React made it very clear. They call it Learn Once, Write Anywhere. Typical managemnet still reads it Learn once and deliver everywhere. When these kind of half listening happens followed by the team which is excited for the new words in the the market, end result follows, what is called Buzzword Driven Development.
In reality it is much better to follow the instruction as it is said. Just learn once, but one has to write it everywhere.
Knowledge reamins the same, but implementation is different for different platforms. It is same knowledge base, not same code base.
Matured teams can harness it and go on with it for a long time. Teams can swap and memebers and still can function. Product rolls out with ease. For fresh teams can move with speed.