iOSLib?

Will there be something similar to MacOSLib for the iOS version of Xojo? Something like this would be needed to stay up to date with apples ios releases.

macOSLib is an opensource project create by a knowledgeable group of volunteers. Their work is done as a contribution to the RS/Xojo community. Whether or not they choose to continue and to add iOS functions is totally up to the members led by Charles.

Everyone can start one. Probably on the beginning there will be a lot to be done with declares as the framework will be very limited on the 1.0.

Since iOS is just MacOS with a funny hat, many of the needed functions will already be in MacOSLib, and I expect we’ll be adding more as time goes on.

In other words, you’d just use MacOSLib for your iOS apps. As we are given constants for the iOS target, and discover functions that won’t work or need be handled differently, we will add the needed code through pragmas.

[quote=42657:@Kem Tekinay]Since iOS is just MacOS with a funny hat, many of the needed functions will already be in MacOSLib, and I expect we’ll be adding more as time goes on.

In other words, you’d just use MacOSLib for your iOS apps. As we are given constants for the iOS target, and discover functions that won’t work or need be handled differently, we will add the needed code through pragmas.[/quote]

You beat me to it. A whole lot of non-graphical Cocoa modules would work on iOS as they do on OS X. The graphical ones probably would all need to have their own versions, but a lot of the code would be recycled.

Thanks :slight_smile:

I would mind contributing to iOSLib. I do think iOSLib should be a “separate” (duplicate) project, so we could figure out what works and what doesn’t and not mess up the existing MacOSLib. I’ve taken a look at the MacOSLib code and it looks fun.

So, December should be the iXojo release? Perhaps we should come up with a different naming scheme. For example:

Xojo.Desktop
Xojo.Web
Xojo.Database
Xojo.iOS (When another platform is added, rename it to “Xojo.Mobile”.)

The Xojo namespace is reserved. You’ll need to pick something else.

I actually meant Xojo itself. Kinda like how Xamarin names their products (Xamarin.Mac, Xamarin.Android, etc), Xojo could start naming them like the way I suggested. (Xojo.iOS, Xojo.Web, etc)

Creating a separate project would be a lot of duplication of effort.

In the new framework that will initially appear with iOS support everything Xojo. is reserved for/by Xojo and it’s frameworks.
The old framework full of global names will still be present, so things like Format will still work.
But long term everything will move to the new framework and be inside the Xojo namespace so you can create whatever you want outside of that namespace & not have naming conflicts etc.

Yes there will be something like Xojo.iOS etc - but until it ships there’s really not much you can do with it (or even prepare for)

Actually, not much if you duplicate the MacOSLib project and take out the OS X bits such as the UI. (NSAlert, NSButton, etc). That’s what I was trying to say.

[quote=42694:@Norman Palardy]In the new framework that will initially appear with iOS support everything Xojo. is reserved for/by Xojo and it’s frameworks.
The old framework full of global names will still be present, so things like Format will still work.
But long term everything will move to the new framework and be inside the Xojo namespace so you can create whatever you want outside of that namespace & not have naming conflicts etc.

Yes there will be something like Xojo.iOS etc - but until it ships there’s really not much you can do with it (or even prepare for)[/quote]
Thanks :slight_smile:

Many of the classes and functions within MacOSLib apply to iOS too, and the same will be true for future additions to the project. If those classes and functions have to be added to two different packages, it’s duplication of effort. I just don’t see the benefit of doing that.

About what will work under iOS ; what about MBS plugins ? Any preliminary thought ?

Because iOS restricts loading dynamic libraries plugins will have to be handled completely different than they are today.
Any apps distributed through the app store MUST be a single statically linked binary.
This will likely require changes to how plugins are delivered to you by plugin authors & then how they are incorporated into the applications you build.
So initial releases for iOS may not support plugins.

So, in essence, if I understand right, MacOSLib may probably work apart from platform limitations, but not plugins ?

I better learn MacOSLib, then.

Thank you Norman.

[quote=43324:@Michel Bujardet]So, in essence, if I understand right, MacOSLib may probably work apart from platform limitations, but not plugins ?

I better learn MacOSLib, then.

Thank you Norman.[/quote]
I’d expect something like that initially