Future development


I develope a lot applications with VB.NET and I’m happy that i found Xojo to develope for iOS devices.

How are the plans for the future development of Xojo for iOS? The project of Jason King helped me a lot to integrate many features in my app, like barcode scanning or take pictures. From my opinion it should almost be integrated in Xojo ;-).

Will Xojo bring more features for iOS in the future, like more controls or integration of notifications, etc.? I think Xojo for iOS is unique since you can create with the Basic-Syntax rapid great applications, but at the moment I miss more features to support iOS.

Marcel; welcome to the Xojo ecosystem.

I am not a Xojo employee, but I will dare answer: Xojo is committed to supporting and developing the product for the supported platforms. (i am fairly certain that I am not making any promise Xojo cannot keep :wink: If I am wrong, someone will set me straight pretty soon! )

As for when new features will be there, well… they will be here when they are ready. (we all love to hear that, don’t we?) A number of people posted classes and controls for IOS on the forum, so you are likely to find what you are looking for, or at least the inspiration you need to roll out your own controls.

As a former VB developer, I can say that you will find a very hospitable home here, not only for IOS development. I espcially like the ease of development for web apps. My desktop apps can run on Windows, mac and Linux with minor adjustments (and sometimes, none at all!)

Welcome, and enjoy!

Xojo has announced its intention to add more controls. However, given the extraordinary variety of cases and possibilities, chances are you will need to rely on Jason’s iOSKit and Ulrich’s iOSLib for more time to come. Let alone because you may find yourself requesting things that simply nobody through about before.

I was using VB back in 2001 when I discovered Real Basic, which Xojo has evolved from. And have not left since :slight_smile:


To be honest, I did expect more iOS controls in R2016 but due to other priorities (64bit, …) it seems iOS has been left in the cold for awhile. With the current iOS controls there is not many things you can do and that is a bit of bummer Imo

Fortunately, Jason and Ulrich did (are doing) a great job of giving us several new iOS controls with their iOSLibs.
They are not as easy to implement as you would like but they most certainly help making a good iOS app.

My guess is that when 64bit is fully integrated, Xojo Inc will focus again on iOS and add more useable iOS controls/functionality for sure.

Sure, but how long is that going to take? The list of 64 bit work is still rather large.

At the risk of sounding pessimist, I doubt iOS will have its full complement of controls soon. There seems to be so much work to do for the new Arm goodies, for the usual Apple ultimatums (when will they force 64 bit on MAS ?) that yet again the “crossies” like Linux, Windows and iOS may have to wait.

I suggested half jokingly Xojo buys dtPlugins to incorporate their technology, but is it such an utopia ? Xojo iOS is now one year old, and apart from Container Control and dynamic controls has changed very little since 2015R1. How is it Geoff described “aggressively add new controls” ?

Without external help, it seems Xojo iOS is all but stuck. It would make sense to use external brains.I am not sure it would be dishonorable for Xojo to acquire engineering from Jean-Paul Devulder, Jason King and Ulrich Bogun. Let alone to provide ScrollView or a better iOSTable, which are extremely sorely needed. Would that not be a solution when engineers time is so precious ?

Whatever happens, anyway, as demonstrated in the past by MBS, MacOSLib and WFS, there will always be need for access to the framework, would that be through declares or plugins, to go further than the basic possibilities of Xojo. I cannot help but to compare that to customized cars : they start standard, and with the adjunction of more and more parts, they become roaring monsters.

That does not even account for third party tools and subclasses where ingenuity has little limits.

I have to agree with Michel. I had high hopes for the XOJO implementation for iOS, until it was released and it became apparent how absolutly anemic it was. While I have an appreciation for the efforts that Jean-Paul, Jason and Ulrich have done in an attempt to provide a way to fill the huge gaps in XOJO iOS, I personally look at these as “band-aids” (no offense guys), and that the iOS version of XOJO should provide a near parallel (where possible) programming experince to the desktop version.

At the risk of being swatted down by XOJO managment, I am still of the opinion that at this time the best way to create iOS applications is to learn SWIFT (and folks, the learning curve is NOT that bad)

I beg to differ about the “Band Aid” nature of the available libraries. Intrinsically, there is very little difference between calling the framework in Swift, or through declares in Xojo. In practice, the result is equivalent.

Where indeed Swift and XCode are vastly superior is that they give you access to the entirety of the framework without filter, to access all the controls properties (at the risk of being overwhelmed by the paradox of choice) and that the Apple Library gives ready to use examples not unlike the best Xojo LR.

Now the question is : does one really need that full power for the kind of application Xojo users want to create ? Second question: does every Xojo user feel like learning Swift, even if, I agree, the learning curve is not preposterous (unlike Objective-C). Third question : is it not preferable to be able to reuse existing code for the program logic, rather than having to rewrite everything ?

I would not oppose the two. Xojo iOS for all its failings is still a fantastic way of moving from Desktop to iOS for people whose programming skills are mainly or exclusively Xojo. Even if, after outgrowing it, some move up to XCode.


64bit is already here and is working for most part. As far as I know there are not that many issues to be resolved.
I think we are going to see Xojo IDE 64bit pretty soon.

About iOS:
As I already said, Xojo iOS is more or less useless if you want to make a decent iOS app.
The problem is that many Xojo iOS users do not have the patience anymore and are already learning Swift (which is imo pretty easy to learn and above all the new code language for the near future).
I think Xojo Inc is aware of this and we are most certainly going to see more iOS goodness soon. Only then Xojo Inc will see some good cash return. I highly doubt they are making good money with the current iOS-state.

And I didn’t mean the use of “Band-aid” to be derogatory… I meant it as “something required to fill an existing gap”

Probably not… until you get to the point of “Why can’t I do this, when I see other apps that can do it”

More the question is… How many people need to get iOS products to market, regardless of which tool.

Of course it is, but that is not an option today is it? The other side (one with which Norman disagrees), is what of the day that XOJO iOS IS feature complete, and these fine developers decide their efforts in the current iOS libraries are no long fruitful… How much code will need to be re-engineered (or re-written completely)… [Is Swift immune to this… no, not entirely, but at least XCode tells you what needs looking at]

You know what; Xojo could perhaps talk to the ioslib developers about including it in the framework. Now that would make a whole lot difference. Perhaps a good talk about this could help bringing this in the light.

If Xojo would use ioslib and basicly make a framework (namespace) thing out of it, and documenting it. That would make alot of progress on the iOS framework. A major thing is documenting such so it’s understandable, with tiny examples and such.

You may be overlooking a factor in the development of these libraries, and I know you are no stranger to that motivation : the pleasure of discovery. That is what drives people, me included, who create third party tools and utilities. Probably also the pleasure of sharing.

Sure, if and when Xojo iOS gets to the point where it has enough controls, methods and properties to do pretty much the same thing, there will always be someone asking “can I do this ?”, and that will not be possible with standard Xojo. If you look at it, Desktop has been around for quite a while, and still, not a day passes without some declare snippet being shared in this forum.

Michel… don’t get me wrong… I admire what Jean-Paul, Jason and Ulrich are doing… and I would be contributing as well if my motivation was in that direction… as it is I have offered up SWIFT code to help point directions in some cases :slight_smile:

And yes, Declares still fill a hole or two in Desktop… but they are the exception much less than the rule.

[quote=239661:@Christoph De Vocht]64bit is already here and is working for most part. As far as I know there are not that many issues to be resolved.
I think we are going to see Xojo IDE 64bit pretty soon.

I’m glad you are so optimistic. I am not. I would bet it not happening in R1. Maybe R2 but more likely R3.

For Windows at least, 64 bit is not at all complete. With no internal manifest, AFAIK executables are not conformant to Microsoft recommendations for Windows 10.

From reading the posts, it would seem that the Mac version is not entirely immune of pimples as well, if for just mentioning one, the unreliable split with long strings, for instance.

Another concern is the still incomplete landscape of third party products. For a significant amount of projects, it is still a darn bad show stopper.

Compound with that the arrival of the Pi and Arm. Not only that new platform probably did steal away some engineers time, but in addition it seems some users are not very nice about the fact that 64 bit for the newcomer is not yet ship shape. Pi owner are certainly blessed with they new playground, but it feels very much at the detriment of the other platforms.

I am a bit concerned that so much dispersion will mean still not quite complete products yet in 2016. Neither complete iOS, nor full 64 bit… Everything sort of betaish…

For what it’s worth, adding Pi support took away very little time from other projects. Almost all of the work to run on the Pi was work that also had to be done for 64-bit Linux.

In my opinion the Xojo people accomplished a lot in the past year. Their team is small but I can see they are working hard.

I admit in the present form, we cannot use Xojo 64bit because to me it does not seem stable enough (based on what people wrote on the forum).

I also like to ask people to be fair and to make sure to leave emotions out of their replies when something is not working as expected. In many cases it was difficult for me to get the real information behind those emotional reactions. Do not get me wrong, I can understand the frustration and when it makes you feel better, just post them Only realise that for others, it will be more difficult to observe and understand.

I cannot comment on IOS, however based on what I read in this community, people already building nice applications for IOS with Xojo.

I come out of a time (1984) when we had to program with very little resources. I can remember putting an application inside 5KB of RAM. I still benefit from that time period where I had to find many workarounds in a very limited environment. Some people does not seems to realise how feature rich Xojo is and how many other ways there are to accomplish the same thing.

It is not good to make somebody else timetable. Like Norman says : “its ready when it is ready”. I am a very satisfied Windows RB-RS-Xojo user since version 5.2 and I am patiently waiting for the moment 64bit comes out of beta stage.

Be creative!!! Only then you can compare yourself with the Xojo engineers. Should I not be a good Xojo evangelist (just teasing)?

I also started to program in the eighties, and around 1984, I was actively using my own resources for menus and stuff in QuickBasic, including a time slicing thread system.

But we have come a long way, and thanks to Mac OS X , Windows and Linux, a lot of that is now part of the framework.

I am a Xojo enthusiast, and never miss an occasion to say how much I awe to RB for my modest success. But bland satisfaction is not what drives innovation. There is nothing wrong in saying “can do better”.

To give my 2 cents into this thread: When I started iOSLib, I wasn’t aware of how huge the API is. If I had been, I probably wouldn’t have begun. Declaring all that stuff is one thing, and I bet the engineers could do this faster, but their genius lies in making it all easy to handle.

Yes, it’s true, XCode and Swift give you the benefit of the full set of includes. But then you still have to figure out how to use them, which means you have to understand programming styles of at least three decades – or you have to go on a wrapper solution hunt. I am still fighting with my iOSLib tableview implementation, and even if iOSTable makes one miss a few things, I bow my head to the engineers for making that beast so easy to handle.
What I am trying to say: Xojo-izing API calls is a lot of work. Even if the engineers would spend 50% of their time in iOS development, I don’t think they’ll be able to come out with 10 new controls each release.

It may be true Swift isn’t that hard to understand. But then I am bound to only Apple platforms, and most of all I personally prefer the display of separate methods and properties Xojo offers. Even when I open a project I haven’t looked into for more than a year, it only takes me a few minutes to understand the basics again. I’ve never been able to with different IDEs in the past. He who makes no comments shall profit from a structured IDE :wink:

In a nutshell: I don’t think a fully native Xojo iOS solution can be accomplished that fast, if ever. We will have to help ourselves with declare libraries or plug-ins for the next years. So what could we do to increase the usability of the solutions? Documentation was mentioned here, and that’s surely a thing. It eats up incredible amounts of time, but without any solution stays a exclusive expert’s tool. I have spent the time between the years for adding Wiki pages, but I doubt I have reached the 20% mark by now.

I am aware that the existence of at least two big libraries (and a lot of other add-ons) isn’t an ideal scene. I admire the modularity of iOSKit – only want two controls? Kick out the rest and have a light weight project. You can’t do that with iOSLib where a strong inheritance scheme exists, which makes it on the other hand possible to use almost everything from everywhere (and have everything accessible in debugger) – in the end, they are all NSObjects and Views. That’s IMHO good reasons for both implementation schemes. Question remains: What could we do to further increase the iOS experience? Any proposals?