Can Xojo please put attention on improving Mac applications built with Xojo

There are several areas where I hope that Xojo will put their attention on next. These are areas that affect this long term Xojo developer on a regular basis, it irks me the extra effort we have to go through to make a modern Mac application.

This venerable swiss-army knife of a control, is too complex for a 3rd Party to replace, but it’s stuck in the 90s.
I have been able to bring true alternating rows (that support desktop tinting) to it, and to make the scrollbar look like an overlay scrollbar from 10 years ago, but there are things I cannot do without considerable time and effort, to get things that other tools provide for free.

  1. Modern scrolling: It does not support elastic or momentum scrolling. It can be faked by enclosing it a NSScrollView (which requires declares or a plugin). However that too can incur problems.

  2. Doesn’t like being in a NSScrollView; the Listbox by default does not like being moved around without explicitly updating it’s location. It doesn’t update correctly, it consistently doesn’t handle clicks correctly. It requires additional code to remap it’s actual location on the window to where it thinks it is.

  3. Doesn’t like being in a NSPopover; just like a NSScrollView it hates being in a NSPopover (which has been around for 10 years). Same symptoms as the scrollview, except it requires some real low level hacking to fix (which “fixes” it for every instance of the listbox within the application) or replacing with a custom built control, because it’s mouse positions are off.

This control has been around since Mac OS X 10.0, yet Xojo still doesn’t natively support it. Adding it via declares or a plugin, causes problems as several Xojo controls, as they simply HATE being moved around.

I’ve lost count of how many different versions of scroll view I’ve written over the last two decades, each one fixes some issues, while others appear.

Another long time UI interface element from the Mac that Xojo doesn’t support (and should). These can be added via declares or plugins, but again some Xojo controls misbehave when used with NSPopovers and trying to patch events to make these work, takes considerable effort.

Console Applications

  1. The Xojo made “Resources” folder does not adhere to Apple’s code signing guidelines, and forces people who build localized helper apps with Xojo to have to create their own localization system.
  2. Mac Console applications should include a Info.plist within the Mach-O binary at build time, it’s not impossible to add it later, but this is a tremendous amount of work. I’ve made slow progress over the years.

Application Size
A simple “Hello World” GUI application is 15 mb. One window and UB. 10 mb is the XojoFramework. 5 mb is the blank executable. I’d really like to see Xojo put some focus on making it smarter to strip out the things that are not needed from the framework and base application.

I think I’ve covered this quite in depth for a while, so I’ll only summarize it here. With some extra elbow grease Xojo can alleviate some of the bottlenecks and help their customers to not only easier adopt workers, but also to gain much better performance than the current solution. While I agree with @Björn_Eiríksson that the Xojo framework needs re-writing to correctly adopt concurrency, I don’t have his faith that this will ever happen, so some improvements to workers could at least benefit some customers in the meantime.

I don’t have as much time as I used to, to sit in front of the computer, so I totally missed the full impact of the control renaming during the 2021r3 betas. It is probably too late for Xojo to think about reducing the impact for 3rd party control vendors now. I basically have to duplicate and modify my work to support 5%~10% of my customers.

Mac App Store
Apple’s two faced attitude of “Developers MUST pay 30% of their profits towards the upkeep of 150,000 API”, while at the same time telling developers to “roll your own” when it comes to required crypto (and other standard functions that don’t exist on a phone) for the Mac App Store, is frustrating, it’s also frustrating that Xojo has and includes a crypto library in built applications, but does NOT support the required crypto functions for the Mac App Store. So to sell apps in the Mac App Store, we’re supposed to include two crypto libraries. I have previously outlined which functions are required, in a Feedback case.

There are many other areas that Xojo really should be putting attention on IMHO. These are just some of the issues that I run into.

As always, I am open to discussing these points (and more) with the Xojo team. I’m willing to put in some work or provide code where I can, as I do care about a product that I’ve been using for 25 years. I won’t, say re-write the entire Xojo listbox for FREE, I still got bills to pay, mouths to feed, car to maintain, etc etc.

In closing, this is probably one of the last times (if not the last time) that I’ll try to advocate for improvements to the Xojo development tool. I can’t help Xojo if they don’t want my input and I need to accept that, afterall it is entirely possible that Xojo doesn’t need my input at all.


Hi @Sam_Rowlands

Please, is there already a Feedback case # for this one?

I agree 100% but this has been asked a trillion times and I highly doubt this has any priority.


Add one more for the ListBox: It still doesn’t support Apple’s VoiceOver Accessibility features.

Give Feedback cases 16328 and 14613 some love:

Add Apple VoiceOver support to ListBox

VoiceOver Accessibility description field is missing

1 Like

Mac apps have always been RB/RS/Xojo’s crown jewel, but I agree that Xojo now needs to take a look at what a modern macOS app looks and feels like, and what functionality is expected. Xojo-built Mac apps without declares or plugins, while still native, are starting to feel a little different to other non-Electron apps on my Mac.

I know the answer will be to make specific Feedback requests (many of which already exist), but this is too broad a subject for us as a community. We could all spend days typing up many hundreds of Mac Feedback cases, which may not really be helpful to Xojo in this case. I really think this is a subject for Xojo themselves to spend some engineering resources on.


Maybe that’s why the license prices went up big times to have some cash flow for a new macOS engineer. :thinking: Really hope so…


sure… :slight_smile:

1 Like

I don’t believe the price increases will have that level of impact.

Xojo should have multiples tabs or switching the control list in the control library, and the first one should be “X Shared” and hold the current list of the cross-platform common core, next should be “Windows” and hold specific native controls only available at runtime for Windows, next one should be MacOS with tailored native controls that can have a set of options different from the x-shared one and needing #If TargetMacOS in the code in x-shared code, there we could have controls like a TableView (NSTableView) to be used instead of the Xplat Lisbox, … then Linux. (order of OS popularity)

And also must provide a way to people to design multiple User Interfaces (windows) that only will be compiled for chosen OS’s, like: Window1:(X)_Windows_(X)_macOS_(X)_Linux for X-Shared, or Window1:(_)_Windows_(_)_macOS_(X)_Linux for a Mac only, and the SAME window version, same name, as Window1:(_)_Windows_(X)_macOS_(_)_Linux for a Windows only version

Legacy code and Windows and controls would work transparently, old Windows will get set as “compile for all” as (X)_Windows_(X)_macOS_(X)_Linux

The Xojo problem is not a lack of knowledge to create a “native” listbox, but because a native listbox is not compatible with other platforms, so they need a way to separate native controls from cross-shared controls.

I disagree. We’re seeing that already with iOSMobileTable and (I would assume) AndroidMobileTable. If that’s correct, it’s going to be a nightmare. I can’t download the Android preview right now to confirm. We need cross platform, not multi platform.


The above suggestion is both. Cross and specific when you need specific. Some IDEs don’t even allow cross, just specific, just native for each one, so Xojo would be ahead here.

That’s for complete different projects, that differs from desktop that is just one project, with multiple interfaces ONLY if need or desired, most people could just use x-plat controls in x-plat windows and be happy.

Although piDog’s DataView is built entirely using Xojo code on a canvas control (not a Listbox subclass) and has LOTS of features not possible in a standard Listbox. I can’t address how it behaves in some of your specific use cases, but I can attest that Jim is VERY responsive to adding features or helping you understand what to tweak in the source code (if you license the source code version).

This is not to take away from your other points – just to note that it possible for a 3rd party to replace it. I do license the source, and it makes me very aware of the complexity of what Jim had to pull off here.


There is no better replacement than the native NSTableView which Thomas did a great conversion for.
I never ever use the Listbox anymore (at least not for macOS). All my apps use the NSTableView and imo it’s the only correct way when making an macOS app.

1 Like

Xojo should have multiples tabs for switching the control list in the control library

(found this mistype rereading the post but can’t edit it anymore)

if @Geoff_Perlman needs the money for a new Mac engineer like @Sam_Rowlands and he says they’ll do the job…I’m willing to renew now for 2 years…and maybe everyone else Pro of this forum will do the same to help


Thanks everyone for taking the time to provide your feedback. We agree with your discussion of adding modern updates for macOS and controls, it was actually already in our internal plans. However, we can see there’s enough interest to include it in our public roadmap as well, so it is there now. If you have specific feature requests for this, please put them in Feedback.


Awesome, thanks so much for listening!


Thanks @Dana_Brown for listening.

I know you never give deadlines and estimated dates and we know the post where it was explained to but in the same time same as other vendors do it would be nice to have at least a rought idea on when to expect things. While it is a major breaktrough that you do listen and you do improvements it will not be very usefull if they come in 3, 4 years from now, hope you get my point . In my case due to the old controls like the famous listbox, lack of responsive windows, outdated inteface and many others, and the fun part is that was the only reason they decided to cancel a huge project that i was working for the past 7 years just to move to Web which give them the freedom to have a more modern interface. So indeed changes are always welcomed but if they are to late they are useless, and don’t take it bad here, being able to say we will have this feature maybe end of x month it could help to think and do estimates and have hope that we could have but when seeing items on upcoming for years or bugs not fixed for ages and they are important, that is not a nice fact to fight for, and explain that we cannot do anyting and we need $$$ plugins to maybe do things that could break any time or not be supported just because we dream that could have all we need maybe one day.

1 Like

Easy guys… We’re still waiting for Modern Windows 10 stuff… Now we have Windows 11.