API 2 conversion

I accepted the Xojo menu item ‘change everything to API 2’, and first compile got over 2,000 errors?
I can’t face changing so much or addressing so many errors. Is there a secret I don’t know about, a simple change that dissolves most of these errors? its quite a put off, and I don’t know if it is a necessary conversion to enable me to launch my App on the MAC Appstore? Help appreciated.

Prefixes and/or suffixes significantly help when it comes to converting to API 2. If you strictly followed whatever your standards are, you can do some clever RegEx replaces to update most of the codebase to API 2 quite quickly.

Unfortunately this is one of those “I wish I knew that before I started” bits of advice.

No, API 2 is not necessary for this goal.

1 Like

In one of his last posts Greg asked the poster something like this: is there a reason why you want to convert your project to API 2?

Thank you for your reply. Then I need to know “what is the point of API2?”, and am I confusing it with simply upgrading objects to for example, ‘desktoplistbox’?


I do not know the answer. As for me, since I develop for desktop apps only, apart than updating some objects to newer ones (for instance, toolbar and segmented button) I keep working with API 1.

1 Like

Thank you, that is helpful. I am also a desktop app developer. I will stay with API1. I will also update some objects to desktopobject.

Without autocomplete developing in API1 is pretty useless. Mixing API1 and API2 doesn’t work either because my brain only retains one set of instructions. You can bet your behind that any new improvement will only be for API2.

1 Like

Thank you Beatrix, this sounds like very good advice, but if I may ask again “what is the point of API2?” what does it do differently, what advantages, what improvements does it offer??? I can’t seem to find out WHY API2?

Nobody knows. There are some improvements in wording of methods or events. 99% is busywork. The desktop controls have no improvements whatsoever.


Have a look at what I did:

In terms of the controls, I couldn’t see much, if any, improvement. In terms of String and database methods, a great improvement. But we already had those a couple of years ago.

These blog posts may be helpful:


to this day, it appears it was to Make Xojo less like Basic and in general make the languaje “look” modern… Instead of actual improvements.

1 Like

Adding ‘desktop’ to controls was the most pointless of all the changes.
The names were ALREADY different from controls used on mobile.

This has sadly made it less consistent, not more so.
A seamless cross platform system would use the same control names to enable easy code re-use, while making the attributes of the controls variable if need be.

You know - like the way that a button or a window does different things on Mac and Windows already - not all styles are possible, but the code still runs.


if you came to Xojo in mid-2019 or later, you do not have to ccare about API.

You learn and use API2.

It is different for people who learned and used the original API: they have to learn all as if this is new (and yes, this is new).

Thanks Tim, that offers a way forward.

great advice, step by step safety, thank you.

Dana, thank you. the 2 videos are excellent and have explained what I asked. It isn’t necessary to convert, I can convert to new desktop controls and do them individually. I can relax now.


That is wrong and a missconception. Looks like you missed a lot from the API2 fiasco.

The real pointless change there was the renaming of the EVENTS in the controls. Xojo spent a lot of time doing that change in the regular controls, but when they release that, they finally realize that LOTS and lots of third party controls and plug ins broke so they reverted to the old event names and then create another classes with new names for the new events. The “desktop” was just marketing in the end.