Xojo's Feedback App - Not a Xojo Web App?

@Louis_Brauer1 thank you for xojo web testimony, it’swhat i’m guessing xojo web would be, you make some rational points.

Xojo is also good for iOS development and I can prove it :slightly_smiling_face:
95% of my revenue comes from Xojo made iOS apps that are available on the App Store.
These apps are used daily by several thousand users and have been downloaded several million times. If that isn’t sufficient proof, feel free to PM me for more details.



The question is how many declares do you have to know, and how well do you need to know iOS itself to create the apps.

For X-platform desktop, the vast majority of the time (well at least mac/Win) it is very little for those OSes.

How true is that for iOS?



@Tim_Parnell has created Strawberry Software - Lifeboat which enables you to deploy Xojo web apps to other servers. I currently use Lifeboat with Digital Ocean.


The early implementations of iOS required an inordinate amount of declares to the simplest things.

Although I switched to another development tool because of that 4 years ago, I still keep an eye on Xojo iOS. They have made much progress. Today’s implementation seems decent.

To be fair, Desktop is not that immune from declares and plugins. Fortunately, Christian with MBS plugins provides a simple solution, making the process transparent. For those who love digging under the hood, MacOSLib provides a collection of declares.

1 Like

Nowadays, close to none!
If you start your iOS project with both iOSdesignExtensions and iOSKit (both of them are free on github) you most likely won’t need to write a single declare.

Almost each time I write a declare for UI stuff, I add the feature in iOSdesignExtensions, so that the whole community can benefit from my knowledge and experience with iOS.
I have also contributed to iOSKit for more advanced features such as sending SMS, displaying a menu and so on.

To be fair, just like any other system, you need to know how it works to be able to make an app for it.
When I started making iOS apps, I was an Android user. My first app was rubbish because I wasn’t accustomed to Apple devices. After purchasing my first iPad and iPhone, my second app became a leading player in its market.


If you are not familiar with iOS, you should get an iPhone and perhaps an iPad. That will give you a feel of how an iOS app behaves.

In particular, if you mostly did Desktop and want to develop for iPhone, you got to refactor the UI first in terms of controls. CheckBoxes, Popupmenu don’t exit there. You also need to break what used to fit in one screen in several views.

1 Like

Hi Brock,

Yes, exactly. I was hoping that they would use their own product too, as this not only helps them to identify issues with their own software, but to improve it, as well. For example, Steve Jobs believed that it was an embarrassment for Apple to use “Microsoft” Office, so he required all Apple employees to use iWork instead. Guess what happened to iWork? Tons of bug fixes started to happen!!

There are some things that I wish were better about Xojo Web:

  1. It’s not very mobile-friendly.
    Nowadays, about 50% of the web viewership is done through a mobile, portable device of some kind. By not being mobile-friendly, it greatly reduces one’s ability to sell a client on using Xojo Web.

  2. Xojo needs to realize that a lot of companies are not going to use Xojo Cloud service.
    Instead, a lot of companies are going to do their own hosting (for security reasons) and need clear, step-by-step document on how to set up and run the website, especially with an HTTPS connection (think “Let’s Encrypt”, which is free, etc.)

  3. Xojo really needs to improve the testing of the Xojo Web.
    To me, it seems like Xojo Web is not being thoroughly tested enough before features are being released. For example, in the past few years, there have been quite a few frustrating, glaring bugs that should of been detected and fixed before the product was released. For example, the tabbing order was messed up. Listboxes weren’t sorting correctly. Recently, if you were using the Firefox web browser, the listbox would suddenly hide all of its records. It’s bugs like these that cause developers to lose faith in a product.

Don’t get me wrong, as I really do love Xojo! Yet, improvement is needed, in my humble opinion. :slight_smile:


The advantages of eating your own dog food. :smile:


No matter how they try to sell us this, to me that’s an admission that Xojo Web isn’t fit for real-world use… :man_shrugging:


I love Xojo desktop and console. The web-edition is just not it.

Don’t know anybody running serious business with a Xojo webapplication else than simple internal productivity tools on a local intranet.

1 Like

Maybe, but in their defence, there are entire companies based around web-based bug tracking / task tracking software (e.g Basecamp, Jira, arguably GitHub). It was probably just too big a project for Xojo to handle as well as their main product.

I for one am glad they are doubling down on the IDE.


If by chance, that dog food is the same you eat. But if you are in a different developing target…

Xojo is working on a developer tool and its IDE and you are creating a video | film script writing (and drawing) tool: not the same dog food; great chances you fall into bugs they will never see (if there are some bugs there, of course).

Several do, @Louis_Brauer1 does, and several others too as far as I know

1 Like

We have a huge Web 1 Application.
Web 1 was more or less reliable and still is. Definitively more than Web 2 is now after two years. But both aren’t comparable to real web development frameworks.

And I highly doubt that Web 2 ever will jump over the line to become a competing web development tool. The decision to use jQuery, alone tells everything.

But the decision to move to Gitlab is still one of the best they made recently imho. They should focus on their product, and not on a ticketing software. Building a feedback software with the abilities and connectivity of Gitlab is a huge project and the time is better invested in Xojo itself.

Sure, how would they “eat their own dogfood” then one might ask? Two usual ways:

  1. By closely listen to the customers. Here are plenty of frustrated developers, they are a huge source of ideas and wisdom. I never heard, that someone was invited in a feedback meeting - apart from the “testers” channel.

  2. By initiating OpenSource Projects and contributing to them. A lot of software companies (us included) are starting os projects, sharing code, taking part in some and building a community of volunteers. I can only imagine what we could build, if Xojo would invite us to. Not for the IDE, the compiler or something. But for controls, internal tools and so on.


They have one dog food project that should be used as test, it’s called Eddie’s Electronics. They just need to complete such demo project as a Web multi-user app with multiple features like scrollable lists, parallel insertion, exclusion, data retrieval, panels, PDF report, etc and expose it to users. When they can make a small full featured demo to work, that’s a dogfood project at some extent, at least to prove basic functionality, and useful to find bugs after new releases, find memory leaks, misbehavior, session dropping and session recovery tests, crashes, inspecting logs, etc.


Most specifically, “the practice of using one’s own products or services.”

Eddie’s Electronics is an example project and will never be dog-fooding.


A full featured product, compiled with your tooling, exposed as an usable demo, used to prove it’s working correctly every new edition of your tooling, is, as I said, at some extent.

No is not. It is just an example.

1 Like

What I described is not a sample. It’s a full featured test case, live, inspectable by the outside and inside.