I honestly don’t like this TARGET stuff peppered thorough out common code. I would define an interface and have the window and page implement the interface.
You can’t do other than pepper code with #If Target like pimples on an adolescent face, if you want to use controls from another platform in the code, as it would simply not compile.
As an engineering challenge, that is interesting, but I persist thinking it is not a terribly bright idea from a commercial standpoint for someone who hopes to sell the class. Multiplatform means one sale only. One class per platform means potentially several sales. Call me mercenary, business is business. Especially on such a limited market.
I also fear such a salad bowl would potentially be harder to debug. Not to mention support.
I have been using Xojo Web for long enough to know that desktop users will feel it is not Kansas anymore. There are things in the Web framework that do not react at all like desktop, and may impede a one-size-fit-all smooth operation.
You could keep one codebase for all platforms to minimize duplication of common code and still sell the platforms as individual licenses.
Of course any add-on that directly manipulates UI controls is quickly going to get overwhelming with the nuances of it to be terribly difficult to maintain. So I agree that anything touching the UI directly probably should not be cross-target.
However many of the infrastructure underlying stuff can be cross-target quite easily.
Indeed. I believe rational use of modules should make it relatively easy to drop the logic in each project.