Why Xojo instead of Xcode?

Targets iOS
41

[quote=262561:@Johan van Breemen]Is creating a table really that much harder in Xcode/Swift or is it something that you have to get used to? Don’t get me wrong, I’m not arguing you. I have no experience with UITable in Xcode; only some other basic beginners stuff.

Can you elaborate on this; maybe with some examples? Such examples would help Xojo in explaining people why Xojo would be better.[/quote]

OK. Nothing better than practice. Here is a page that shows how to create a simple table in Swift : How to make a simple tableview with iOS 8 and Swift

As you can see it is way more involved than simply dragging a control in the layout editor. If you do need all the bells and whistles of iOS, get ready to read a lot in the iOS LIbrary, and do the plunge. If all you need is a bit more than what Xojo can do, have a look at the excellent https://forum.xojo.com/31758-dtplugins-are-now-free which provide a good iOSTable class that does much more than the basic one, but is a lot simpler to use than Swift.

Also, Xojo iOS is not quite as limited as it is natively with the Open Source classes :
GitHub - kingj5/iOSKit for the iOSKit series of classes by Jason King
GitHub - sbeardsl/xojoGestures: XoJo module for attaching UIGestureRecognizers to Views for a module from Stephen J. Beardslee which brings gesture support.
GitHub - UBogun/Xojo-iosLib: A library extending Xojo's iOS feature by adding extension modules and classes. from Ulrich Bogun for extended modules and classes.
GitHub - Mitchboo/XojoiOSWrapper: Module that brings legacy and additional functions to Xojo iOS from yours truy for a wrapper that provides better compatibility with legacy code.

Time is another part of what one may or may not have in abundance. In spite of its extremely limited set of controls and properties, Xojo iOS retains what made me use it for so many years for Desktop and Web : very fast development, and intuitive usage.

But I do agree : XCode is not the monstrosity it has been made to be. Especially since Swift.

42

We know

[quote=262567:@Dave S]* those controls that are there are missing many standard properties (borders, colors etc)
[/quote]
Support for iOS styling etc - we know :frowning:

Was, in part, a design goal so things ARE extendable by declares, user additions (iOSLib etc) much more easily than they are with other frameworks
iOSUserControl is the result of this to make it possible to add native controls that we did not implement

IF we’d chosen to make “every control on iOS” you would not have had anything for a longer period
And we needed to find out, from actual usage, what things are / are not possible given the design we chose to pursue
And now we know

[quote=262567:@Dave S]* is two versions behind in the level of iOS supported (iOS7), so no support for LaunchScreen (just bloated Launchimages)
[/quote]
If only Apple would document the format :slight_smile:
Instead we’ll likely have to use the Xcode installed tool that takes an xml file and spits out a LaunchImage.nib file :frowning:

Apple shifting strategies on how to do this is truly a pain in the rear

Autolayout makes dealing with multiple devices sizes & resolutions much simpler
But there are those who would rather hand code everything
And, even in Xojo, you can disable autolayout on a view (declares) but whats not exposed is the sizing a& layout passes so it is more difficult than in Swift etc
But thats where we have to make choices about what is / isn’t in / out & what is exposed or not
We’ve had to do that for just shy of 20 years

43

Since it’s so hard to keep up with with Apple, would it make sense to step away from native controls?

iOS is so different from Desktop and Web, due to the difference in frameworks and controls. The coolest thing about Xojo Desktop is how you can build a desktop app for the targets. It got harder when Web arrived since the controls were different. Then iOS arrived with a new framework and more controls that are different.

If Xojo had the same framework for iOS, Desktop, and Web along with controls that work on each it would make development incredible.

Is this insane?

44
  • Declares… I’m not saying it SHOULD NOT be part of XOJO… I’m AM saying it has become the RULE, not the exception
  • Every control? no, but how about the standard suite in UIKit? even that is not implemented
  • LaunchScreen.Storyboard - seriously, you guys cannot reverse engineer 28 lines of XML? even I managed that… sorry… Oh and the current format IS XML,not NIB
  • [quote]Autolayout makes dealing with multiple devices sizes & resolutions much simpler[/quote] I agree to disagree
    I have iOS apps that have totally different layouts based on the realestate per device… AL is fine if you want an “elastic” type display.

What is so hard to keep up with? Apples iOS framework has not change (significantly at least from a controls/visual perspective) since iOS 6… and if XOJO went custom controls for iOS, then that would be a HUGE mistake in my opinion… might as well use Java as the backbone (just kidding)

45

Moving away from native controls means that your app looks “different” and doesn’t use the new themes / look when apple updates things etc
And it means we have MORE work to do - not less

46

Don’t most apps look different anyway?

47

[quote=262583:@Dave S]* Declares… I’m not saying it SHOULD NOT be part of XOJO… I’m AM saying it has become the RULE, not the exception
[/quote]
Going into iOS we knew we’d never have “everything users wanted from the outset” so we designed to make it possible to use declares for those missing bits
iOSlib is actually a pretty decent showing that it is possible to extend the basics in a lot of ways as we intended

[quote=262583:@Dave S]* Every control? no, but how about the standard suite in UIKit? even that is not implemented
[/quote]
At some point we HAVe to decide “this is where we start” and ship that
Otherwise you end up with “well we could add” over & over and never ship
I have an associate thats had that problem and has not shipped his product thats been in development for 12 years :stuck_out_tongue:

We get that people think we set that bar too low

[quote=262583:@Dave S]* LaunchScreen.Storyboard - seriously, you guys cannot reverse engineer 28 lines of XML? even I managed that… sorry… Oh and the current format IS XML,not NIB
[/quote]
Check out what you get in a compiled app
Its NOT an xml file
The xml file would get passed to ibtool & compiled (which if we go that route we WILL never get the ability to compile on Windows or LInux - design maybe but then its a half solution)
We’ll see

[quote=262583:@Dave S]* I agree to disagree
I have iOS apps that have totally different layouts based on the realestate per device… AL is fine if you want an “elastic” type display.
[/quote]
AL works even when you have different layouts per device but …

Lets see - they have how many engineers working on the framework for iOS alone ?
Then Xcode ?
And …
This is not a new issue regardless of its iOS , OS X Windows linux web etc
We could always use many more engineers than we have

48

[quote=262584:@Norman Palardy]Moving away from native controls means that your app looks “different” and doesn’t use the new themes / look when apple updates things etc
And it means we have MORE work to do - not less[/quote]
Xojo has plenty of competitors but one of Xojo’s most important selling points is its use of (mostly) native controls. I hope Xojo Inc don’t underestimate this. I’m pretty sure they don’t or they’d have taken the easier route a long time ago.

49

I think most of us find the SWIFT language itself very easy to use. However, I find the darn Xcode IDE an overwhelming difficult to handle beast.
Maybe things have changed recently but I did some minor SWIFT work in the past and hope I won’t have to do it again. I just can’t seem to wrap my head around Xcode. (I remember having the same issue going from plain C to Borlands C++. It took me forever to finally change my way of thinking.)

50

Marco… clarify please… having trouble wrapping your head around “Xcode” (as in the IDE) or around “Swift” as the language?.. I find the IDE to be different that XOJO (somethings I like better, some I don’t), but for the most part, its type your code, click build, fix errors, repeat…

What I DO like about XCODE (and it would be cool if XOJO did this), was point out certain types of errors the instant you made the mistake (certain syntax errors, unused variables etc) instead of having to compile and/or “analyze”… but then each is different

51

It’s Xcode the IDE that I find difficult to handle. I feel lost.
Not Swift the language itself. I find it difficult to wrap my head around Xcode. Where to find things, the interface builder and it’s inlets, how things are organized. Basically the whole structure of how things are hooked together.
I see Xcode itself as a the mountain to climb. But I’m sure I’ll see the light if some larger project requires me to use Xcode and I need to bite the bullet.

52

If Xojo iOS becomes the great tool it can be, there will be less reasons to go for XCode. However, Xojo will never be XCode, just like it is not Visual Studio on the Windows side.

The main advantage of Xojo is to remove the paradox of choice. If you look at it, the XCode IDE is not that different from Xojo’s, but instead of a dozen properties or events per control you got 50 or so. Direct access to the framework is great, but yet again it becomes a puzzle where one has to decide over so many possibilities.

Finally, as great as Swift may be, legacy code is an important asset for many of us. Having to rewrite everything is a royal pain in the you know what. Yes, the new framework requires refactoring, but it is way easier than starting from scratch.

53

IRT Xcode the IDE - it is more complex than Xojo, and that can be daunting. On the other hand, the Storyboard (sine iOS 8) has greatly simplify the interface building bit. And once you get over the initial “hump” with Xcode, it really “gets out of your way” and doesn’t interfere with you when coding. And I think XCode has a better debugger than an Xojo.

I am not a fan of C++ or any of it’s variants really- I greatly preferred Ada to C++, but lost that battle when Microsoft went the C++ route I am afraid. Xoxo is far more like Ada than C++ to me, and not that far away from Swift. (Swift version 2 is much less “C” like than the previous versions, and Version 3 is even more so.)

What you can do with Xojo is dive in and have a working app in a very short period of time, as long as you do not need to do something that Xojo has not already provided for. Some complex things in Xcode are either super simple to do in Xojo, or just flat impossible. Tabular data was a killer for me in Xojo, while doing the same thing in Xcode is simple. Observers and Notifications are still a puzzle to me in Xojo. :slight_smile:

The most annoying thing in Xojo is that the layout constraints seem to be out of control. Dragging a field on a screen can result in a disaster. I am pretty sure that will get fixed in a newer release, but … it can make visual design almost impossible. At least, for someone like me. I want the editor/design tool. compiler, debugger and all that to get the heck out of my way when coding.

Xojo does an excellent job of that on MacOS and Windows. And Xojo does just keep getting better and better in most areas. I expect that trend will continue and accelerate. Competing in the development tool arena these days is not an easy thing to do. Apple and Microsoft give away their development environments, and Linux has so many different (and free) environments that competing in that space is really tough.

-Paul

54

Xojo is the combination of the IDE and the multiplatform language, while Xcode is just the IDE where you can create your projects for OS X and iOS in C, C++, Objective-C and/or Swift. If you need to rework the code for a Web, Windows or Linux deployment… you have to start over (mainly).

Even if we focus on the Xcode IDE itself, lots of “native” developers (those that are developing for iOS from 9 to 5) find preferable to jump into Jetbrains AppCode or use both of them.

The main point about Xojo for me is that it leads to faster development cicles and it is way faster to “catch”, both the language as the IDE itself; as the ability of having multiplatform deployments, of course!

Sure, you can’t appoach all the kind of projects for iOS that are possible using the, Apple blessed, CocoaTouch framework, but I bet it is possible to achieve faster deployments (from conception to final deployment) on those that are possible using the capabilities found in the standard Framework of Xojo.

Lastly, I find insane having to upgrade the OS (and all that that implies) just because the Xcode IDE needs it.

Javier

55

Javier, I would agree wholeheartedly if this thread was anywhere but in iOS. In the present state of Xojo iOS, even the simplest projects require such an amount of declares and workarounds, it actually take more time than XCode.

I regret that sad state of things, but until Xojo iOS provides minimal support for hardware, a decent complement of controls, and the same kind of events, property and methods that come without saying in Desktop and Web, it will be not much better than a toy.

56

I just recently made my first iOS App using Xojo. Just to see how it feels making an iOS App with it. It’s called TipWiz and is a really simple App (but i am proud of it :slight_smile: ).

I was shocked about the lack of missing Hardware Features and Controls and have no desire to make another App for iOS in Xojo’s current state. I really look forward to the already announced upcoming improvements.

57

Hi Javier - I can see your perspective, even if I do not necessarily agree with all of it. Coco and Xcode are both IDEs and both include a large number of sophisticated development tools and aids.

Xoxo targets Windows, MacOS, iOS, Linux, Web, and Pi targets.

Xcode targets MacOS, iOS, tvOS, watchOS, and various other speciality targets, some of which use or require external build tools.

Xojo has a broader and more diverse target selection, which inevitably means that each target will be less well supported than native development tools in some areas. If you wish to deploy on both MacOS and Windows, then Xojo is a natural and preferable choice to either Xcode or Visual Studio, Xamarin not withstanding.

For deployment only to Windows or only to MacOS, iOS, tvOS, etc., the native tools still have quite an edge on Xojo. Speaking bluntly, and from the perspective I would use to choose a tool for a specific revenue generating project.

This appears to be especially true with iOS targets, which is not unexpected, because iOS is a newer supported platform. And a very complex one at that. I do not think it is even reasonable to attempt to develop and deploy a marketable iOS app from Xojo without using something like Jean-Paul’s very well done libraries.

58

In some cases this is not as daunting as it sounds. For myself, I created a number of specialized SWIFT classes (mostly as a learning experience), but they are now part of my daily toolset. These classes encapsulate the sometimes more complex SWIFT syntax into methods and functions the supply a more famiiliar syntax.

Also, I have come up with what I consider a very straight forward mean of doing screen layouts for all the device types (including the yet to be released iPhone7), that does NOT use Interface Builder (I actually find THAT more complex than XOJO).

59

Dave, no matter how easy you find XCode and Swift today, you did have to learn it, and am sure without your very real programming experience, it would not have been a walk in the park.

My point was to stress that Xojo made it easier du reuse existing code, even in its infantile stage. It may also very well be that some people could simply not master Swift and XCode.

On a personal level, I will think very hard before embarking on the creation of new apps in present Xojo iOS. I rather spend more time creating the minimum tools and libraries I need to be productive in Swift. Like Paul says, native tools have an edge. It would not be the first time I had to do it. Back in 2013 when it became clear that Xojo had no intention to go further than Win32 and Desktop, I embraced VB .NET and VS to create Windows Store (now UWP) apps. Bad workers blame the tool, but conversely, it is extremely difficult for a good worker to use bad tools.

60

[quote=268876:@Michel Bujardet]Dave, no matter how easy you find XCode and Swift today, you did have to learn it, and am sure without your very real programming experience, it would not have been a walk in the park.

My point was to stress that Xojo made it easier du reuse existing code, even in its infantile stage. It may also very well be that some people could simply not master Swift and XCode.

On a personal level, I will think very hard before embarking on the creation of new apps in present Xojo iOS. I rather spend more time creating the minimum tools and libraries I need to be productive in Swift. Like Paul says, native tools have an edge. It would not be the first time I had to do it. Back in 2013 when it became clear that Xojo had no intention to go further than Win32 and Desktop, I embraced VB .NET and VS to create Windows Store (now UWP) apps. Bad workers blame the tool, but conversely, it is extremely difficult for a good worker to use bad tools.[/quote]

Few year ago, I was at the cross-road. I have paid for licences for PB, PB (the x-plat one) , Xojo and also bought the official books on Qt and also some books on Obj-C and having explored them, I had to decide on one. I chose Xojo for the x-plat advantage. I updated 2 Xojo licences the past few years they are still current but I kept stutttering due to lack of and not up-to-date features, especially for Windows.

Recently the past few months, I put myself back on the cross-road again. This after I realize that no matter how easy it will be to use Xojo, it just simply lack the latest features that Apple and Microsoft are putting in their new and yet newer OSes.

I have gone back to re-look VB and C# while also dive into Swift. I am surprise this time, I have taken an 180 degree turn and like .NET now while I hated them in the past. Swift is so much easier then Obj-C.

Yes and when they release a new OS, they release the tools for the new features immediately. No need to file a feature request, no need to get people to vote, and then wait years nothing happen as what I have been noticing and reading in the forum. The irony is native tools are free.

I am ready to do away with the x-plat intention.