Why Xojo instead of Xcode?

Xcode with Swift seems to make developing for iOS a lot more easier than it was with Objective-C.

Why would you prefer using Xojo instead of Xcode considering that Xcode is free and Xojo costs $299 per year?

I would like to hear opinions from people who have experience with developing in both Xojo and Xcode.

NB: I’m honestly interested in this. It’s not my intention to criticise Xojo in any way. I understand that Xojo cannot give their product away for free.

For me it’s very simple. I’m a Windows developer and Xojo opens the iOS world to me. I did have to refactor a bunch of my core library’s, but that also prepares me for x64 and the whole new framework. It’s done I’m ready.

Without Xojo I wouldn’t even be bothered with iOS.

Curious… you say you are a Windows Developer and Xojo opens the iOS world … .But Xojo iOS requires the installation of XCode… so I’m not sure why being a “Windows Developer” was relavent, as opposed to refactoring XOJO desktop for iOS.

Personally I have found the iOS for Xojo to be robust in a few places (very few), and lacking in way too many others, so without getting into a flame war or violating this forum, I’ll just say I have found SWIFT to be much more productive use of my resources in regards to iOS from both a cost (its free) and support (100% native) point of view.

NOTE : the above are the opinions of the author, and should be respected as such.

Let’s try the reverse. What about refactoring Mac code to Windows or Linux later? Xcode can’t.

True, but this was posted in the iOS topic area, therefore one would assume that going from OSX -> Win/Linux was not a factor :slight_smile:

I agree to Wayne.
The Time you Need to learn Xcode (Swift) should not be underestimated.
My Personal experience is - i needed only 3 weeks to start developing my first app and After another 4 weeks it’s ready to ship it to my customer.

But i agree to Dave that xojo is a Little bit poor in terms of Programming iPhone features (GPS, camera etc.). I don’t wanna fight with all this declares and foundation stuff.
So many thanks to the members of this forum doing all the work !!!

because its NOT Xcode :stuck_out_tongue:

Exactly Norman. But also having refactored my classes I can now use them on iOS & Desktop & Web apps. For me that’s the big win :slight_smile:

Yes it’s not Xcode - But for example:
One of the most used (by me) controls is the Table Control. In one of the learning videos there is an example how to solve the issue of selecting a row by code.

Why is this not a standard method of the control? Why do we have to deal with all the declares?
I’m really a fan but that should be solved by xojo.

[quote=197305:@Hans-Jürgen Müller]Yes it’s not Xcode - But for example:
One of the most used (by me) controls is the Table Control. In one of the learning videos there is an example how to solve the issue of selecting a row by code.

Why is this not a standard method of the control? Why do we have to deal with all the declares?
I’m really a fan but that should be solved by xojo.[/quote]

http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice

XCode is fantastic if you want ALL possibilities of the framework. But then you have to deal with an overwhelming amount of options. Not to mention the real complexity of using the framework directly. NSTable being an excellent example of truly Kafkaian native control. Programming even in Swift requires constant reading of the Mac Developer Library which, as some of us already know, can be quite esoteric.

Xojo on the other hand offers a smaller set of abstracted controls where there may be less choices but in large part, they can be used almost without reading documentation. That simplicity is key to very rapid development. And this works cross platform without refactoring. The price is that not all options of the framework are directly available, so if you want something out of the fixed choices, you got to go declares.

With Xojo, you drive the car. With XCode, you got to build it first…

What I like in Xojo ist that all the different (mostly not needed) Xcode project-settings are hidden. We see only the things that we really need.

On the other side I would like to see more more focus on bug fixes and improvement in supporting the current platfforms over more new supported platforms. For example the discussions of basic features like currency, retina support, date and time pickers, creation of pdf files are not necessary.

I would be glad, if the Xojo would spend more time to invest in the basic features that developers expect to be available in a development framework.

Yes i wanna drive the car ;-))
But where’s the Problem to add the most common Properties and Methods to the controls?
What’s about the most common features of my iPhone (gps, camera etc.) ?

Actually i have to pimp my car before driving!

[quote=197312:@Hans-Jürgen Müller]Yes i wanna drive the car ;-))
But where’s the Problem to add the most common Properties and Methods to the controls?
What’s about the most common features of my iPhone (gps, camera etc.) ?

Actually i have to pimp my car before driving![/quote]

I was talking about Desktop.

iOS is unfortunately much too young, and even if its level of abstraction already helps people who have never programmed in Objective-C or Swift, it is not by itself yet ready IMHO for professional applications. Fortunately, there has been an unprecedented effort from people like [by alphabetic order] Stephen J. Beardslee, Ulrich Bogun, Jean-Paul Devulder (dtPlugins), Jason King, Antonio Rinaldi and Christian Schmitz (MBS) to provide a lot of missing functions like GPS and camera, among others. Don’t throw the baby with the bath water just yet.

If you are competent enough and accustomed to XCode, nothing wrong going on with it for iOS. But for a lot of people who have been programming in RB/Xojo for a lot of years, and with the help of declares and third party classes already available, pimping is reduced to a minimum, as well as the cruelty of learning a new language together with the iOS native framework.

This whole discussion seems specious to me. Either/or is usually the mark of limited minds. Xojo instead of XCode can be idiotic if you already master the Apple development tool. But certainly XCode instead of Xojo for people who have never touched either Objective-C or Swift is severe and unusual punishment.

[quote=197318:@Hans-Jürgen Müller]But where’s the Problem to add the most common Properties and Methods to the controls?
[/quote]
The problem is simply that iOS is huuuge. While the engineers are busy adding 64bit for Desktop, their capacities are bound to this topic. I think Xojo’s improvement speed is really high these days. You can be sure more controls and properties will be added over time, but I understand that the situation is not fully satisfying when you feel stuck because a certain implementation is missing. For those pieces, it would be good to file a Feedback feature request or assign your points to an existing one if you haven’t already. That makes it easier to align the development schedule with developer demands (if possible).

About declares: A bit simplifying you could say the benefit of XCode lies in the Apple supplied libraries. Without them you would have to declare the methods yourselves just like you do with missing features via declare in Xojo. After that, you are bound to a language that is less easy to read (which of course is a very subjective viewpoint) and therefore needs more comments and documentation. I’d probably be able to use XCode for my projects now, but I must admit I never felt tempted to. I prefer the visual representation of methods and properties as single objects in Xojo’s Navigator and the readability of the language too much.

IMHO the main problem with declares is the complexity of the syntax. Once you understood it, there’s not much difference in building your own custom Xojo class or one based on declares. Mostly. Controls like tables are really beasts, and the Xojo engineers put a lot of work into creating the iOSListBox which really takes away a lot of the pain you’d have to go through in XCode. And yes, there’s certainly features missing. While it’s not perfect to depend on 3rd party additions, it IS a workably method that can be the solution to many problems. And with the introduction of 64bit Xojo built plugins there’ll be better ways to implement those libraries – once installed as a plug-in, you’ll never notice if you use a built-in function or one added via plug-in. Which is again very much like XCode then where you have to import the libraries you want to use too.

Or, with the words of Voltaire: “One day everything will be well, that is our hope. Everything’s fine today, that is our illusion”

That would be a real improvement.

One of the advantages of using a high-level language is you can keep from getting your hands dirty. In many cases, Xojo on the desktop offers more than one function to do the same thing. One that is higher-level and requires less work than the other.

As a self-taught programmer, one of the reasons I choose a language is because I want to be abstracted from the tedious work of coding everything myself. Isn’t that why we all create reusable functions? I want to focus on the business rules and not the programming rules.

To the extent that Xojo can do this work for me, it will be much more valuable and usable to meet my client’s needs. Having created my first IOS app, I’d have to say that there is lots of work yet to be done. Will Xojo do that work for me… sure they will… it just requires patience on my part.

About the time I became proficient in Swift, I’d probably regret my decision because Xojo will have added those changes that made me consider using Swift in the first place.

I don’t like declares, not because they don’t work or I don’t understand them, but I know that someday they will be unnecessary and there may be differences that have to be resolved because Xojo native functions may work differently or be more robust than what those declares do.

The one thing that has become abundantly apparent is that it is extremely hard to develop apps that run in the web, desktop, and IOS. Sure, they may share some code, but that means you have a lot of duplication of effort maintaining that code in more than one app. My question is, will the day ever come when you can share controls across all platforms? Is that even on the roadmap?

Actually, that may not be exactly true any longer. Microsoft is putting the Xamarim support into Visual Studio, and that kind of adds Mac and iOS support. More complex than Xojo (or Livecode) but with better support for iOS. C# if course.

And Swift is open sourced now. Swift is as easy to learn as Xojo, and in some respects, is more orthogonal and better defined. (Shrug) Does not make Swift better than Xojo, but as little as three weeks of working in Xojo does reveal some of Xojo’s weaknesses, as well as its strengths.

Really world class iOS programs written in Xojo look to me like they have to do a whole lot of DEFINEs to get to where you need to be. On the other hand, simple little iOS prograns are a snap to do in Xojo.

Declares are not functions. Declares are information for the compiler about functions in the frameworks on OS X (or iOS, Windows, or Linux). So these “declared” functions are the native ones, not the Xojo framework functions.

This is more or less impossible to achieve with a 3rd generation programming language. These language usually rely on accessing the native OS functions. 4GLs like Filemaker are different – but then you get one ugly piece of user interface…

One thing will make developing declares for iOS and OS X easier: I just saw that Feedback request 14820 - Module external function editor should be updated for Objective-C functions now seems to be implemented and is waiting to be tested. It would mean that for example all needed Cocoa declares could be moved into one module as external methods and then be used within all classes beneath that module.

To make Things clear - i like xojo, but my Point of view was: if there is an implementation of a Control (like Table) then i would provide it with the most common properties and methods.
This is my attitude of development- call me a limited mind but this is my opinion.

So let 's remain serious. I would never change to Xcode, because the balance between advanteges and disadvanteges is positive (for xojo and for me).