Is Xojo Mobile Ready for Prime Time?

Hey all! Opinions sought!

Would you build cross platform Mac, Windows, iOS, Android in Xojo? Is it prime time for mobile?

I currently have a nice looking (and complicated) Xojo app for Mac/Windows. (See www.officetime.net). I have a companion native app for iOS. I need an app for Android so am considering redoing iOS to a common mobile code base.

My options are:

  • Flutter / Xamarin mobile. Xojo desktop.

  • Xojo for everything. (But do widgets, Apple Watch app, etc natively and integrate.)

Iā€™m aware that all the Xojo views would have to be redone for mobile. I just donā€™t know if the quality is there for an external facing B2B app.

In a word NO

1 Like

NO

You cant have a ā€œcommon mobile code baseā€ in xojo, iOS and Android are different proyects and have a lot of differencesā€¦

Android is still on ā€œbetaā€, for xojo this is the equivalent to a pre alpha where the users do the QA jobā€¦

Looks great. I also had to do a lot of custom views for my apps.

I have a few multiplatform solutions and I use:

  • Xojo Desktop
  • Xojo Web 1.0
  • B4X WebServices, Android and iOS

It works really well.

1 Like

I have also a few xplat apps and I use JavaFX FOR desktop all platforms and with Pro Server for Web and with GluonMobile for iOS and Android and I can share the whole Code.

+1 for using B4x , have used before with a Xojo Web 1.0 backend.

B4A and B4I and B4J can also share a big amount of Code, yes. It is a bit less than I can share when using JavaFX in my configuration while my App is in one project for all targets. But at least I can share my application logic with B4x without any problem, thatā€™s for sure.

Superlist was built with Flutter.

1Password was built with Electron.

Omnifocus is written in SwiftUI (Apple donā€™t support Windows or Android, albeit Android support is available via a 3rd party transpiler) Blog - The Omni Group

Thereā€™s a reason why these bigger companies do NOT use Xojo, I just canā€™t figure it out /s

This might be a clear example about how behind Xojo is, their fixed size mobile UI doesnā€™t really work in the Android universe with such a variety of screen sizes.

it is something that Declarative UI is design to solve.

1 Password was a native Mac App but they went electron to go cross platform, while dropping many features

This is correct, but it gave developers easier access to more platforms, increasing the size of the target audience. I dislike Electron apps, but I can see why companies choose it over Xojo.

I said at the time, it was clear example of how Xojo not only dropped the ball, they then started chasing butterflies around the pitch. Xojo had the potential to compete with any number of tools, but their lack of vision and blinkered ideals, caused them to completely miss the boat on how other companies are making cross platform much simpler for developers.

1 Like

Well not trueā€¦ you can use external included Files with e.g. Objects using them in multiple Xojo Projects (targets). This is how i made Win/Mac/Linux Projects with quite the same codebase 10 years ago.

Fair

Watch & such dont integrate
And you still, at this time, write an iOS project & and Android one
Mobile is not a single project that compiles to both yet

Will it ever? :man_shrugging:

Your guess is as good as mine

If it does it will be some time away

1 Like

Do you need a separate project for iOS from desktop (and Android)?

Yes
Each is a separate project

The only way to share data is with external items? That sounds like a pain unless Iā€™m mistaken.

Well not the ONLY way
You can use Git sub projects

BUT be aware that the shared code will likely have many ā€œspecial casesā€ where iOS does things one way, desktop differently, and Android another

And some restrictions have leaked out into how you have to write your code
Like
https://tracker.xojo.com/xojoinc/xojo/-/issues/75911
https://tracker.xojo.com/xojoinc/xojo/-/issues/75805
https://tracker.xojo.com/xojoinc/xojo/-/issues/75285
https://tracker.xojo.com/xojoinc/xojo/-/issues/75195

and several others
https://tracker.xojo.com/xojoinc/xojo/-/issues/?sort=created_date&state=opened&label_name[]=Android&first_page_size=100

To speak truths: even CodenameOne has issues and leaks in functionality. But not that ones. Exactly thatā€™s the problem. Half baked features for pulic use. Hmm. Not the best method to have customers which are happy with the project.

Oh I do not expect anything will be perfect

What I dont expect is to have to alter how I code in Xojo because of how Kotlin works and what it can / cant do that might be different from Xojo

Today if you want to use byref parameters in Xojo for Android you cant
YOU have to manually work around that - but only for Android
Everywhere else it works as expected

And this isnt the only place this sort of thing comes up

1 Like

That for sure Norman. I was changing to CN1 while I have an API consistency and I have exactly one project and one UI for IOS and Android. For me it makes no ense to have different APIā€™s for my projects. What shall I say? Xojo has started to use Kotlin language for Android what I really can understand. They could have done it so that they would compile for the ARM platform their own, Xojo project. But that would need much more efford to build. And would have much more troublemaking points in it.

As you decide for Kotlin it is like always: youā€™ll get the GOODS and the BADS alsways one with the other. So you may have a few problems.

1 Like

Superlist looks pretty sweet. It doesnā€™t look ā€˜nativeā€™ on Mac but it looks professional enough that I donā€™t think anyone cares.

One of my first tests in judging a new environment is can it produce a good UX for the user. Early Java apps always failed that.

1Password feels substantially clunkier and less stable since switching to electron. Donā€™t know if thatā€™s electron or just a new code base.

I just wanted to say thank you to everyone who has commented. Particularly to those who have obviously put time into this. :slight_smile: In interests of not spamming the thread, I wonā€™t reply to everyone individually.

I think the lack of a common glue between iOS and Android is clear. Looks like we have

  • Separate projects for each with some kind of shared external code
  • Separate views for all controls which would be a huge rewrite for me
  • Arbitrary restrictions on coding. E.g. Not passing byref

It sounds like itā€™s do-able but it will be a huge cluster-unfun of wrappers, subclasses and case handling.

Contrast that with, say, Flutter which as I understand is pretty much write all views to the same controls cross platform.

1 Like