Poll: Platform code or Xojo

Hypothetical (that’s not so hypothetical at the moment):

MacOS and Windows both include code to a certain thing. (We’ll call that the “platform code”.) It’s fast and works for the vast majority of cases, but fails the standard unit test provided by the maker of the thing. The failures range from some (Mac) to lots (Windows), but are not representative of typical use in either case.

Meanwhile, I’ve created code that is cross-platform and passes all the tests, but is somewhat slower than the platform code. (We’ll call mine “Xojo code”.) (“Slower” means a high percentage on the microsecond scale, like 3 µs vs 6 µs per usage.) It also requires more memory upon first usage, let’s say about 5 MB that persists.

It’s come time for me to publish my package for general use, so I have to decide which way to go. What would you do?

  • Include just the slower but better Xojo code
  • Default to the Xojo code but include the platform code as an option
  • Default to the platform code with the Xojo code as an option
  • You have too much time on your hands

0 voters

1 Like

In the Plugins I often have a C code version and an CPU specific version leveraging some speciality like using assembler or vector functions when available.

It depends, if such thing is related to Unicode, I would like to know the results of using libicu (that Xojo puts into the lib folder, but the latest stable one, icu 68.2) instead of trying to emulate it using Xojo code. If it “fails” I would report such fail to the Unicode Consortium.

I haven’t tried with that one, but I am unable to declare against other included libraries.

This is Xojo’s obligation, not yours. You can use whatever solves your problem.

So far the preference is for the Xojo code.


one source code for all platforms is better just because all apps behave same.
if you include more that could cause more support for you.


Thank you all for your participation. I will default to my own code but make the platform code available too.