Desktop to iOS - easy? hard?

I’m just starting with Xojo, from a background in C and various other languages, mostly on Macs. I have an application written in the 4D language which I am looking to rewrite in Xojo, for the most part with the aim of getting it to run also under iOS (specifically on iPads).

How easy is it to get a desktop app written in Xojo to run under iOS? Is there a lot of rewriting to be done, or is it pretty straightforward?

Jeremy

If your business logic code is separate from your UI, its not too bad.
But if you currently have code written in ‘4D’ then the best way to start is with modules that contain re-usable code sections, and then split the code to work on desktop and IOS front ends

If you want to use features like iCloud and Files, it’s not good.

What does your app do?

you will have to write rest API to handle database connection from iOS. you only have sqlite local database for iOS.
Jef advices are good: separate user interface from logic code using (external) modules and reusable sections.
I’ve done a lot of migration from 4d to postgres (so desktop apps) but have not done any iOS for now.
I also made a tool (using xojo) to import a 4D database into a postgres app

Thanks, both. That’s helpful.

I’m a barrister. It’s a niche application that helps personal injury lawyers in the UK prepare claims for damages by deriving figures from life expectancy data (the Ogden Tables, as they’re known). It needs to store a modest amount of static data (the tables). Under MacOS and Windows, it can paste figures into Word using AppleScript and VB; it would be nice to be able to do that under iOS, but it’s not terribly important. It doesn’t use iCloud but it does get some data from UK government web sites (price indices and state pension ages) from time to time.

A sqlite local DB should be fine. Although it’s written in 4D, it’s not really a database application; it just has a small, underlying DB which is pretty much read-only.

Jeremy

You can store the data in one or more in-memory dictionaries / Pairs , and save/load it from applicationdata as XML or json as you need, if you want to avoid rest API

If he uses SQLite (seems it should fit the use case from his description) then it is natively supported on iOS.

I recommend checking out my iOSKit:

And Jeremie’s iOSDesignExtensions:

As you create the app to fill some of the holes in Xojo iOS.

Thanks again, all. It seems reasonable to suppose that if I rewrite the application in Xojo to run under Windows and MacOS, it won’t be terribly difficult to adapt it further to run under iOS.

Jeremy

I would recommend reviewing all the commands thoroughly and make sure commands your using in desktop have an equivalent and how they operate differently. For those where there is no equivalent I would start work now to find out what you can or cannot do through add ons like ioskit and iosdesignextensions like Jason King suggested. Good Luck IOS can be frustrating because not all the Xojo features are there. Some because the product is not feature complete and some because Apple doesn’t let you do those things in IOS.

IOS Commands

One of the most difficult tasks, though, has nothing to do with code.

Real estate on a phone screen is nowhere near what is available on desktop.

You will probably need to refactor the UI, and often use several views to replace one single desktop window.

Many of the equivalent controls have less functionality in the iOS version, so pay attention to the methods you want to use.

Neither straight-forward nor easy. So much of what we have available and take for granted in a desktop app is simply not available in Xojo’s iOS framework. As Michel and others say above, you are looking at both a UI redesign and a complete rewrite of your data access layer. And Steve’s warning cannot be stressed enough - the control options just don’t compare directly.

Jeremy,

You might check out my XDC presentation from 2018 (I think).

What I did is subclass all the controls in Desk, iOS, and Web and made them all act a similarly as possible. I also created an interface to handle database interactions (one can then create a class that fits the interface for the database(s) you’re using).

It was even possible to drag controls from one type of app to another!

-Bob Gordon