Thoughts on converting from iOS to Mobile

For me this has been a tedious process so far.

I could just change the Super of App to Mobile Application, but couldn’t do that with the events. They had to be recreated.

An iOSView would not allow changing the Super to MobileScreen, the view had to be replaced with a new screen. Again, the events had to be recreated.

An iOSTable would not allow changing the Super to iOSMobileTable (interesting this is not just MobileTable), so it had to be recreated. Again the events had to be recreated.

Methods are also deprecated all over the place, so you have to hunt them down with Analyze Project and make sure it’s not more than a name change.

Luckily, I’m doing this in a new project I recently started, so I don’t have that much to change. But I can’t imagine doing this in older projects where I have dozens of views.

I’m also staring at going to String after being in Text for all my projects.

You don’t need to change it all. The old iOS classes are still there and will be for the foreseeable future. You can mix and match new and old. I have it done in my app and I have no issues.

Art, this wasn’t my experience of converting a large iOS project to use API 2.0: I was able to change the super of App, iOSView, iOSTable, iOSButton, etc. I did this during beta testing so there’s a chance that something has changed since then, but it worked well for me a few weeks ago.

What I did find frustrating was the lack of a way of converting an old event handler to its modern equivalent. I totally get why that shouldn’t be done automatically by the IDE, but it would have saved some repetitive clicking if I was for example able to right-click on the “Open” event that was brought across from an iOSButton and be able to change it to “Opening”, “Action” → “Pressed”, etc. But changing the super worked well.

An iOSTable would not allow changing the Super to iOSMobileTable (interesting this is not just MobileTable)

I’m guessing that wherever we still see iOS in the name of a class, there are sufficient differences from the Android equivalent that Xojo have decided they need to be handled slightly differently. Maybe there’ll be a MobileTable class with some common properties and methods, with iOSMobileTable and AndroidMobileTable subclasses that handle the platform-specific stuff :man_shrugging:

I’m also staring at going to String after being in Text for all my projects.

I found this part relatively straightforward because at least the Text methods share the same indexes as the API 2.0 String methods.

1 Like

When I tried to change the Super, I only got options beginning with “iOS…”. Glad it worked for you.

I’ll start looking into String shortly.

Can you just type the name of the new class? I’m pretty sure that’s what I did.

I thought I tried this and it didn’t work, but now it does. Maybe I had a brain fart.

1 Like

For me the biggest issue by going from iOS to Mobile is that we can’t use @Jeremie_L iOSDesignExtensions and @Jason_King iOSKit any longer. Without that, a decent looking iOS app with Xojo is impossible.

1 Like

I will release iOSdesignExtensions for API2.0 as soon as possible.
I am currently very busy with my secret santa app

If Jason King doesn’t have time to port iOSKit I will take care of it


You should be able to replace the parameters for the coloring functions from iOSView to MobileScreen and for all other control extentions do the same.

It should work again. (As for the design extentions) iOSKit is another monster

FWIW, I was able to convert the iOSDesignExtensions that I use to work with MobileX classes without any problems. I only use a few colour setting methods.

I haven’t dared try to convert all of that!

1 Like

I tried that: replaced iOSButton with MobileButton but I don’t see the method on the button.
Bildschirmfoto 2020-11-27 um 11.46.17

This is awesome news. I didn’t dare to ask. Certainly another donation coming for you…

You just need the handle in the declare and the exends needs the correct type the autocomplete can be wrong sometimes