I have built an App for Apple MAC. Given Xojo is ‘multi-platform’ development, I thought it would be easy to convert this App to an IOS version. Is it? Has anyone done this, what problems are there, does it take much time, OR do I start again?
I’ve tried a few times.
(yes, that means I haven’t succeeded yet, but my needs are specialised)
It’s by no means a ‘one click’ job
Controls are different.
Xojo syntax is different.
if you have kept your business logic away from your UI you will make better progress
A lot depends on what your app does.
Pure business apps with text boxes , database , and radio buttons will be relatively OK
Listboxes need a whole new paradigm as they are on-demand rather than populated and left to get on with it.
And the cost of an iOS licence is very high compared to the other Xojo single-target licences, so unless you have a pro licence, there is an investment there to consider.
With the recent changes to iOS, more code will be common. In the past you had to use Text on iOS while MacOS used String, for example. That at least is no longer the case.
The main difficulty will be the huge difference in UI between MacOS and iOS. You’ll have to rethink lots of stuff.
I only develop for iOS and renew my license when it goes on sale. Interestingly, all my iOS apps “just work” on my M1 Mac mini. So there may be a trend of development switching from MacOS to iOS in the future.
I say give it a go. There could be some paradigm shifts to consider, but once you see the patterns, converting isn’t bad anymore.
This last week I converted a massive program to iOS.
I had to recreate the user interface (obviously) and I had to change all the instances of format to toString, but aside from that it went quite well.
Over the last year or two I’ve tried a few times with zero success, but with the current build it’s become a lot easier.
My current application had a lot of heavy math that worked in realtime with paint events from canvases. These converted over with only a few tweaks from things like g.fontAscent to g.font.ascent (not difficult).
There are a few gotchas with setting font attributes and names, but nothing too bad.
If you use the Einhugur or MBS plugins then you would have been blocked from migrating your code, but those limitations are in the past. There is a current issue with Xojo and MBS not compiling in an App Store friendly way, but I think that’s going to be resolved quickly. In the meantime you can certainly test and develop without issue.
Screen shot attached to give you a sense of it from desktop to iOS.
I’m considering moving to web too, but I think that will be more challenging.
Thank you Jeff, appreciate your knowledge and experience on this.
Art, this is helpful, I like the caution on UI and business.
Hi Chris. Thank you very much for this. It is instructive, helpful and detailed enough for me to know what to review in my App, before investing in IOS from Xojo. Great thanks.
Jeff, thank you for your response, it is very helpful, and apologies for delay in replying.
How can the code I have be transferred across to an IOS project? I can’t see how to do this?
As an aside, I wonder since XOJO is “cross platform development”, why can the code not be more easily transferred [I do understand different architecture and OS etc].
The iOS code we have had for many years previous was very incompatible, (although some excellent work had been done by Michel and others to wrap ‘new code’ in a form that could be called by ‘normal code’)
I could be mistaken, but it felt to me that either Xojo had decided it needed a new framework and wanted to use iOS as a lever to bring everything else in line, or that the person developing it wouldn’t write it unless it was done ‘their way’
Anyway, the newer API2 and recent work on iOS to allow Strings , has made the code much closer.
If you write code in a module for iOS, it’s relatively easy to copy and paste into a desktop project and vice versa.
Ive been doing that recently myself.
The stumbling blocks are only really at the point where you consider the UI.
Anything that talks to a control, and some things that relate to events, need to be recoded.
Which is why I recommended splitting the business and GUI code.
A routine that calculates the amount of fuel required to turn a transport ship around in the Suzez canal can exist in a module, and doesnt need to know anything about text boxes or canvases.
It has input and output parameters, and will work fine in desktop or mobile.
How can the code I have be transferred across to an IOS project?
Literally -‘copy and paste’
Great response Jeff, thanks. I have a large App. And copy & paste would be an enormous task, enormous! I had hoped [maybe wrongly] that I could open the App in Xojo, change the tick boxes for the ‘compile for’ from MacOS to IOS, and then start conversion … but clearly it’s NOT that easy at all.
There is traffic on the forum saying IOS apps, run on the new Apple M1 architecture without recompile, might it possible vice versa I wonder?
That is interesting, IOS ‘just works’ on MAC. I wonder therefore if it can work the other way soon? Clearly screen size, files etc can be different, but the hope comes from ‘Sidecar’, I can run my App on the MACBook and sidecar to my iPad and it looks superb, fits perfectly and operates brilliantly …except, when opening some. Other windows, they show up on my MacBook screen[?].
Sidecar is more like RDP - it’s a screen viewer and controller.
You aren’t running the software on the iPad’s processor, you are manipulating the screen and the input devices.
iOS apps will run on M1 chip Macs because the processor is the same. (doesnt work on intel machines)
Yes, thanks, and I know sidecar is like RDP. I simply meant my app screen fits perfectly on the iPad so I know IF I COULD convert it would look great.
The point of “same chip” is why won’t that work both ways? Just a dream!
My personal frustrations for iPad are
Its INCREDIBLY hard to get data into an iPad app from elsewhere, using Xojo.
(Shared files is widely despised and not understood by users, and Xojo iOS apps cannot open files in iCloud. URLHandler seems impossible to implement too)
the small screen,
the use of a finger as a pointing device (like drawing with a carrot!),
the lack of right-click,
and the lack (for obvious reasons) of being able to hover a mouse over something
Feels like everything needs to be bigger and operable using ‘monkey point’ gesturing.
(Which of course is what Apple appears to be turning MacOS into.)
I simply meant my app screen fits perfectly on the iPad so I know IF I COULD convert it would look great.
Nothing stopping you if its a business app and texty
You could probably reconstruct the display using canvas controls and handling them yourself at a push.
iOS buttons just dont LOOK like buttons
You dont get menus.
And so on.
I have sucessfully co-erced a segmentedbutton control into a workable toolbar replacement.
Apparently, and with Xojo 2019r1.1, you can add a module to an iOS project.
You also can export the module,
You can also import the module.
Please, confirm if this works for you (migrating code from Desktop to iOS project).
Should work fine
With the new Mobile framework, it should be easier than it was before.
One thing I did is subclassed all the controls. So on Web a TextField is an RDDTextField; on Desk, an RDDTextField; on Mobile, an RDDTextField. (The superclass on each was different, of course). Having done that, I’ve literally been able to copy controls (at least Web to Desk and back, haven’t tried it with new Mobile framework yet) from one platform and paste them in another.
Thank you for this detailed response, it sounds a very good approach and simplifies transition.
As a learner, can you give me one example of “subclassed all the controls” please, that would be a great help. I am close to setting up my Xojo built MAC desktop App. for the Apple App.store and no doubt will have some questions for the forum about this too, and with a view to transiting my App to the iPad in future. Thank you again.
Here’s what I suggest… Try a very simple app. Desk with one window and one text field. iOS with one Screen and one text field. Except don’t use the built-in textfields directly. On each platform subclass the textfield as a new class (you might name it “mytextfield”). You may be able to copy it from one platform to another.
Also, we may want to take this discussion out of the forum for awhile. We can do email or phone or both.
can you give me your email to use please. I have hidden this text .