Gaps & ... Other Gaps

When producing a cross-platform solution, you could be lucky, & you're solving a problem that someone else has already more or less solved, so the cross-platform infrastructure gives you enough support to implement the whole solution (given enough libraries).
However, you could be less than fortunate, & all of the googling in the world won't come up with someone else's trailblazing through your problem.

This is when it's time to get creative. A good cross-platform environment will allow you to build your own modules of some sort that are effectively native. In effect, this defeats the whole purpose of having a cross-platform delivery model, but in the real world this is often necessary.

It also means that you will either still need the development environment for creating native apps (or at least libraries), or else you will need to be able to reach out to contractors or out-sourcers who can do that work for you. The good news is that you are now specifying a very tightly-defined piece of functionality.

For example, if you want to use the on-board voice recognition, then you need to get down into a native interface. For iOS, you theoretically can't access Siri. For Android, there often is a way, dependent on the device, to access such services. If you can define your new library's API, then someone else can provide that solution for you - & they'll be able to get it right, quote reasonably effectively, & give you a fair idea up front of how functional the unit will be. They can do that because they are concentrating on a given mobile platform, & because the unit of work is easy to understand.

The gap now is in co-ordinating the piece-workers with the architecture of the solution, managing their deliverables as a part of the project plan, & ensuring that there are agreed-on test cases for acceptance of those units.

That's the new gap.

Once upon a time, it was a matter of having a team that could work on a solution, & they would skill-share to ensure that the components all came together, integrating their tests from component up to UAT. Processes like CI/CD assume that work is continuous & centralised (on one development platform, not necessarily geographically co-located). Co-ordination becomes key once more - relationship management, project management, integration - & there is a rising importance in understanding testing - not just how to perform tests.

Cross-platform development is not a silver bullet, but it changes the game to focus your technical resources on what matters - the UX - & your management resources on what they're good at - relationships.

The More Things Change ...

Once upon a time (& yes, I'm old enough to think of my earlier career as possibly mythical), we used to talk about "cross-browser" issues. Let's say around the year 2000, when the three major browsers were IE (which was getting behind in functionality), Netscape, & anything you could get to run on the Mac. At the time, it almost didn't matter what the browser was on the Mac, as long as you could demonstrate something.

The problem then was that there were lots of different implementations of the HTML standard & interpretations of how it fundamentally worked. There were also a lot of extensions that made HTML useful. It usually meant that you could not, under any circumstances, release a web site unless you either specified the browser (which meant you were stuck on an older version of IE), or else had tested on several versions of several browsers.

Then some **** (company) would release a new browser version just as you reached go-live for your website & marketing campaign, & you had to start testing all over again.

Those days were almost over when HTML5 started coming into the light. I think that we're not only back at square one, but we're worse off with Firefox & Chrome now major contenders in the browser market, but at least you're less likely to do much that's specifically targeted at the Mac - unless you want to.

What really becomes the problem is the cross-platform issues around phones, tablets, phablets, notebooks, airbooks, laptops, & any of a number of variations on the theme, with their different browser implementation engines, screen sizes & resolutions, aspect ratios, etc.

This nightmare just gets worse if you are responsible for launching a web site that caters for desktop & mobile, or else a multi-platform app.

Into this market come the cross-platform development solutions & multi-platform deployment solutions. The former let you build things that can be converted into native apps, while the latter let you build things for an indeterminate infrastructure (like a VM) that can be run on various devices.

This does not solve the problem, but it does make the development easier. Rather than trying to develop multiple solutions - often independently (different developers in different dev envs) - you develop the solution once, as a designer, & then hand this over to an integration/deployment specialist who just has to tweak the application to run on whatever platforms are needed.
Then you click the heels of your red slippers three times ...

This process changes the structure of the dev team. You end up with UX people working hand in hand with DevOps types. You often have platform-based non-technical testers at the end.
This is very different from the traditional position of having devs doing almost everything, & devs who work as testers doing the QA.

If you take the right approach, cross-platform development for mobile applications these days is not as bewildering as it at first seems, but it can't be done by just transferring existing dev models to new technologies.

However, if you don't change your ways, you will be stuck with the same problems that we had at the turn of the millenium.