Questions about XoJo and iOS Apps

I’m currently only doing XoJo Desktop development but am curious. I don’t know that I’ll even want to do IOS apps, but answers to these question will help me decide.

  1. When using XoJo to create iOS apps, how close is it to the Desktop versions? In other words, can code be easily ported, or is it better to just write with iOS in mind?

  2. If I create an iOS app, is there any way to avoid the App Store or similar services and fees and just have some way users can download/install from a website?

  3. Any other things I didn’t mention but should consider?

  1. The design paradigm between touch and desktop is very different. The user interface will be your biggest chunk of non-reusable stuff. You can reuse your logic code if you design it to do so. An easy way to think / plan it is to write thread-safe code.

  2. Not for iOS. It is much easier to side-load on Android, but do remember the Android product hasn’t been released yet.

  3. Yes, when building iOS you still need Xcode. This is important and comes into play in the future when your Xojo updates period has lapsed, but Apple decides you need to use a newer version of Xcode to build iOS apps. You will be required to renew your Xojo license and there is no way around it. This may be a decision point for some people so I mention it.

3 Likes

Thanks for your response Tim. Your answers to 2 and 3 pretty much solidify my reasons not to do iOS development. I’ll stick with the Desktop stuff.

While iOS does not allow side loading, (assuming not jail broken) there are three alternatives:

  1. Enterprise license – this is designed for companies to install there own custom apps for internal use by employees. It is $300-400 year, plus the application process can take months to be approved last i knew. So while it is not practical for most uses, it does exist and how almost all the iOS apps I create are installed. There is no review period. You compile and can install immediately. I do via company websites. These have been famously abused, so Apple is quite restrictive about them.
  2. TestFlight – this is intended to be for testing prior to distribution in the app store, but can be deployed to up to 1000 users needing only their apple ID / email. There is a review period, but I understand it is typically short, especially for an application previously reviewed and where you state there are minimal changes etc. I don’t have experience with these since I use Enterprise licenses.
  3. Ad-Hoc profile – You can pre-authorize up to 100 devices per type (iphone/ipad) per year and install directly to devices PROVIDED you have authorized that specific device ID into your “provisioning profile” on Apple. This is intended for local debug on devices etc, but if you intent is to provide to family members etc it MAY be doable albeit not very practical. Aside from personal devices, ad-hoc installs are a PITA if you ask me.

Bottom line is that aside from jail breaking, the only reasonable alternative is Enterprise licensing designed for internal use by companies.

1 Like

Thanks. None of these options are a good fit for me right now, so I won’t be doing iOS apps.

If you want to develop an app for iOS and Android, you require Xcode and Android Studio. Two different languages.

The real question is this:
Do you want to use a single tool, or do you prefer to use two or more to achieve it?

Remember, XOJO is looking can reuse the code to maintain iOS or Android.

1 Like

I can testify that Xojo code can be written once and shared amongst Desktop, Web 2.0 and iOS apps. I share all my common Modules (external), classes (external), MBS Plugins, databases and images. No UI is shareable. With iOS the Auto screen layout will require a lobotomy, but once you’ve gotten used to it, it’s OK.

+1 for reusing the ‘logic’ like the classes, modules etc.

I don’t reuse any UI between platforms, not just because it’s not possible but because non-native design looks janky. For example you can normally tell if an iOS app has been ported to Android or vice-versa unless the UI has been designed separately - natively for the target.

It’s correct what you say, Adam. The object’s UI is different.

XOJO offers you a web button and a MobileButton. For example.

Both do the same thing, but they are different. One looks good on the web the other button looks good on an iOS phone. The code inside when you click on either can be the same.

To consider. It is possible to make an app in Swift and another in XOJO, both tools using the objects derived from apple iOS. They will look almost the same.

But.

I prefer this instead of programming in Swift and Java, two very different languages.

That is a consideration that the applications engineer should take, depending on your goal.

So, I use one single cross platform tool for mobile (as Xojo didn’t have an Android product - I know this is due ‘soon’).

I reuse the backend logic code between the iOS and Android app. The tool renders all of the controls as native controls for each. The reason I don’t reuse the UI code is because of the differences between Android and iOS such as where you’d expect to see navigation elements, colours, icons, etc, which may make the app look janky to the other OS.

Recently I started to look into iOS programming, and I noticed this as well.
Personally, I edited my Desktop code a bit to get a better start on iOS programming.

The other comments are right, it’s a good way to create the UI layout from scratch. You would need to do this separately for iPad and iPhone layouts.

→ On iOS programming, you would need to put the logic code into the App layer, to share it between the iPhone and iPad layout. Just let the layouts display the results.