If you had to

IF you had to write a mobile app what env would you pick ?
And why ? MUST support iOS and Android

My first thought it go with VS Code and .NET Maui. Hard to go wrong with Microsoft being behind it and apparently committed to it. This means a lot of 3rd party developer support too. And they’ve been doing it for a while now so it’s not something brand new that looks good for simple demo’s but a history. Easy to find training. Easy to find developers with knowledge - especially for mobile.

3 Likes

You wouldn’t happen to know anyone taking on “contract” work that is/was a Xojo dev that could “port” an existing iOS Xojo app ?

I have no personal experience with it (or mobile in general) , but people here have mentioned B4X which supports iOS and android.

-Karen

Doesn’t it depend on what the app would need to do?

No. Sorry.

CodenameOne. While it compiles on both sides native (the IOS Build is an XCODE Build and the Android Build is Android native. That would be my way to punish an App for both while I have only to build up one UI and then one App in one project on IntelliJ. And, if the project has a Jar size less 8 MB: for free. And 8 MB Jar Size are big. If you want to build local: it is also for free. Only Buildservers are not for free.

Not really no
Since we know it cant be Xojo today (MUST support iOS and Android) I’m looking for recommendations from people who are using other tools already

1 Like

I was developing with the toolchain many app and more than 20000 developers are using codenameone for App development for IOS and Android. So I guess it works. Okay. I don’t guess. I know that it works like a charm.

1 Like

I’ve had limited experience with B4x - both the Android (B4A) and iOS (B4A) seem capable. The developer is also very responsive.

1 Like

I was replying to @MonkeybreadSoftware
not your post :slight_smile:

I have experience with Xojo and Java, so I probably could port an Xojo-iOS app using Gluon (Gluon Mobile - Gluon), but that of course depends on what the app needs to do.
Also to consider: When discussing with clients who first wanted an iOS and Android app and after analysing what they wanted to achieve sometimes we came to the conclusion that a webapplication is better suited (one codebase, runs on all devices).

Edit: I was replying to your former post, where you asked for a contractor.

But why GLUON? CodenameOne does the entire Job without any of the problems you have with Gluon Mobile and JavaFX. In my eyes it is a real major problem. Hardware abstraction and everything else you can use also with CodenameOne completely. No need for Gluon and GraalVM. You may read about CodenameOne before choosing Gluon Mobile.

I have used B4A for like 8 years for Android And ported a couple of apps to iOS with B4i.

It is not a single proyect file, but you can share most of the code.

1 Like

Yep results in a Buildserver Project for the B4I Buildserver. Projects working good and reliable but like you said: one project file and Development not under MacOS but under Windows OS. That may e also a problem if the user is a MacOS User which has no parallels installed with Windows.

that’s possibly one further problem. That The IDE is running on MacOS and Windows / Linux. What ever. Development of mobile Apps costs nerves.

1 Like

All good comments and certainly things to look into

I appreciate the suggestions everyone !

1 Like

I worked with WinDev for some years.

Works very well and is also very reliable. It is expensive and uses a dongle. I stopped using it for two reasons: While it is compiling it generated a lot of stuff in the background and deletes it then. After checking this out I saw that they were using a Java background/toolkit. But they did not tell us. I would not say that they are kind of cheating - but it gave me a strange feeling. Other reasons are the complete french community and behaviour, where I felt sidelined a bit.

Hope it helps.

1 Like

I might be wrong, but my understanding has always been, that if their outcomes should run on anything other than windows they will convert it to a Java App (with some limitations of what is feasible on what not). The dongle was indeed what turned me always off.

There is no real botnet XPlat Solution. Sometimes people need to learn that there is Java and C++ with Xplats and with fancy UI frameworks and Look and feels. That is the outcome. Not more not less. And for the File menus it uses the native ones to native behavior is makable. If that is the way? I don’t know. But that they need to work with one or some tricks…man I could make a bet. While there is no other way. (start laughing about that neat arguments for it against Java while java is soooo bad. it is not)

Indeed, if it was that bad, native iPhone fans would have to throw away their device because the NXP chip uses Java for Apple Pay ;-).