Why Xojo instead of Xcode?

Targets iOS
21

Eli

My comment was about being able to develop with one code base for all platforms, not about which one has the best interface. UI is very subjective. Besides, it’s not what I like, it’s what the client likes. At least that’s the way I run my business.

Have you used Filemaker’s Webdirect? I prefer function over form and find what Filemaker has done quite extraordinary. One code base runs desktop (cross platform), mobile, and on the web. I created a very simple app, excuse me “solution” in Filemaker parlance, that does this very thing. Could not have done it Xojo without spending a great deal more time and multiple projects.

I’m not trying to compare FM to Xojo, they are two different tools for two different purposes. They both have their strengths and weaknesses.

22

[quote=197327:@Paul Raulerson]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.[/quote]

Big ditto on that one!

23

[quote=197404:@John Fatte]Eli

My comment was about being able to develop with one code base for all platforms, not about which one has the best interface. UI is very subjective. Besides, it’s not what I like, it’s what the client likes. At least that’s the way I run my business.

Have you used Filemaker’s Webdirect? I prefer function over form and find what Filemaker has done quite extraordinary. One code base runs desktop (cross platform), mobile, and on the web. I created a very simple app, excuse me “solution” in Filemaker parlance, that does this very thing. Could not have done it Xojo without spending a great deal more time and multiple projects.

I’m not trying to compare FM to Xojo, they are two different tools for two different purposes. They both have their strengths and weaknesses.[/quote]

I do not think the comparison is entirely valid. Filemaker is more a programmable database application than a full feature language with native controls and the possibility of declares on Desktop and iOS, or HTML/CSS/JavaScript for Web.

From working intensely with both Desktop and Web in Xojo, I can tell you that they went to great length to make them converge. But like it or not, Xojo does its best to use native controls. That implies differences due to the platform. As a matter of example, take Canvas. On Desktop, it has BackDrop image. On Web, it cannot have that because HTML Canvas simply does not have it. For almost every control there are such differences.

With the excellent job done between Mac, Windows and Linux desktop, one can imagine that Xojo would have loved to have common controls with Web. Or even iOS. But at one point, it must have simply been impossible.

The nice thing is choice. If FileMaker works for you, fine. For myself, I rather use Xojo.

[quote=197405:@John Fatte]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.
[/quote]

Indeed, Xamarin is a nice C## solution. But the same issue applies than Xcode versus Xojo. For people who best know RB/Xojo, the learning curve is not negligible. At that point, if Xojo iOS does not measure up, why not go to the maker and use XCode ? As for Windows and Mac, I’ll take Xojo any day against VS.

24

Michael

Filemaker has a database married to a database manipulation language, and that language has gotten pretty robust. We did development with Visual Foxpro for many years (10 at least) and this was very much the same type of marriage. The beauty of this type of application is that you can accomplish things much more quickly than when the database and language are separated. The downside, of course, is that you do give up some flexibility. Whether that works for your particular instance is a developer/client decision.

The one thing Filemaker is NOT good for is creating MAS apps or distributable applications. That’s why we use XOJO for those applications. In my opinion, if I had a big client application - one that I was going to service onsite - I think I’d first see if FM could handle it because I can get it done faster and adapt it a little more easily.

It’s not that they one is better than the other, it’s that one may be better for particular projects than the other. That’s why I continue to use Filemaker internally even though I spend 80% of my time in Xojo. It’s amazing what I can get done with FM in 20% of my time.

I get your point about the difficulty with control differences for various platforms. However, that’s a consideration that has to be considered when developing using one product versus another.

If I had the time, I’d probably take a closer look at Swift/Xcode for IOS, but then, that’s why I first looked at Filemaker - I don’t have enough time to do everything in Xojo.

25

[quote=197546:@John Fatte]It’s not that they one is better than the other, it’s that one may be better for particular projects than the other. That’s why I continue to use Filemaker internally even though I spend 80% of my time in Xojo. It’s amazing what I can get done with FM in 20% of my time.

I get your point about the difficulty with control differences for various platforms. However, that’s a consideration that has to be considered when developing using one product versus another.

If I had the time, I’d probably take a closer look at Swift/Xcode for IOS, but then, that’s why I first looked at Filemaker - I don’t have enough time to do everything in Xojo.[/quote]

I have not touched Filemaker is so many years I would not dare say I still know about it. Yet it seems to me the more a development tool abstracts from the ancillaries (read dirty chores close to the system), the faster development gets. Xojo abstracts from a great deal of the nitty gritty, so it is way faster than XCode. But yet, some things, noticeably database management, remain DIY. Filemaker is probably one degree higher in that respect, which explains faster development.

Indeed each has its advantages. The reason why I would not oppose XCode, Xojo and Filemaker, IMHO.

26

My life is opposite of John’s as I spend 80% or more in FileMaker and the rest in Xojo, which I’m working to change.

What would help?

  • Merge the desktop, web, and iOS project types into one. The universal project would have Windows, Web Pages, and Views. That would allow you to build for any target with one project and share code between the targets.
  • Get the ‘easy’ iOS declares built into the Xojo language. If the Xojo staff are too busy, hire one of the amazing community declare experts as a contractor. If there are needed declares for Mac and Windows, get those in the Xojo language too.

This would reduce the effort to maintain code considerably!

27

The philosophy of Xojo is not to build calls to the framework into the language, it is to abstract users from that kind of low level messy business. What is very quickly building up is more the equivalent of MacOSLib, which has coexisted for years with Xojo.

I do think Xojo iOS as it stands is just a pale prototype of what it should be. Instead of declares right and left, Xojo iOS should have built in at the minimum ScrollView, Gestures, a decent multicolumns TableView, UIPicker, Printing, and peripherals support (motion sensors, phone, camera, GPS…). There is frankly no reason to become a declare specialist to be able to program in a language which the very abstraction from the framework is one of the greatest advantages. With some degree of luck, this will come with the next versions…

28

I believe merging the different platforms into one project would be an enormous task. The philosophies between the different GUIs are hard to combine. Working with viewcontrollers is quite different to working with windows.

But with the announcement of Xojo built plug-ins somewhere in the future and the platform switches on every method and property, more xplatform comfort will be possible. Of course I don’t mind that much about declares – basically Xojo won’t be doing too different things under the hood. The art of the Xojo engineers lies in making the sometimes very difficult-to-handle API routines that easy to use like most are now (and where they are not, you usually can build your own convenience routines around them).

I don’t see a reason a declare library cannot be as comfortable as the Xojo routines – despite the work you have to put in it. Like Michel said, there should be some more important controls available natively. But iOS is a vast land, and I doubt Xojo will ever be able to deliver all of it, especially because Apple is more than busy re-designing their systems. (Have you seen the whole ABAddressbook framework will be replaced in the next OS versions?) For special purposes, there will be a long-time need for extension libraries. Chances are good they will advance to a point where the user doesn’t notice, except for the increased possibilities.

29

Could you provide me with some real-life examples of when Xojo saves time and/or makes things really easier in comparison with xCode/Swift?

30

http://www.xojo.com/resources/swift.php :wink:

For me, XCode’s advantage lies in bringing you all the API declares so you just have to import them. Xojo’s advantage lies in making it easy to build classes with separate properties and methods around them and in the ease of the language in general.

31

Strange. You start a thread by deleting your post, and now, after a long discussion which you did not participate in, you ask a question that has basically been answered by the many posts before. You probably need to build the same test app in both to see the difference by yourself.

32

Love language wars – but Xojo is a platform not just a language.

The iOS app is probably going to connect to something. That means there’s a process running on a server somewhere. Is that best written in X-Code? I think not.

I want some admin Web apps for in-house and maybe larger customers. Is that going to be X-Code? Nope.

What happens when my iOS app needs to sync with users’ desktops? Windows, Mac, Linux. Will X-Code help me there? Forget it.

What is for Xojo developers a whinge about importing to another project type for others means a new language and framework and a complete rewrite. $$$,$$$

So there’s value in Xojo as a platform and extra cost in maintaining multiple languages and frameworks. Both Web and iOS will become more mature over time however IMHO x-platform delivers value today.

33

That statement applies even to Apples new SWIFT… while the “business” logic syntax in SWIFT is the same, the code to handle the UI is not. For MAC you deal with NSxxx objects and for iOS you have UIxxx
I think it is interesting that even where the NS and UI objects are the same syntax wise, they don’t create a bridge object that the compiler would replace depending on the platform.

This is very subjective. Given two developers, a XOJO expert, and a SWIFT expert, each will swear up and down their way is the best, and for them it is. I have used XOJO for many years now, and am just now teaching myself SWIFT… and there are things I love and hate about both of them… Are they the same things that YOU might love or hate, not for me to say.

34

I totally agree Ulrich. In my mind, the one project idea would have Window, Views, and Web Pages. The idea would be you could build for any platform, but you’d have to use the Windows for desktop, views for iOS, and web pages for web apps.

The way you’d code would be the same, but you could have one project file instead of three.

35

I see, thanks, Hal. Still I believe the effort would overweigh the benefits: The same app method might in one platform just update a control, on the other it would have to switch to a different view and so on. I personally wouldn’t like all the pragma #Ifs, but it may very well be this changes if the systems should share more of their GUI principles.
Currently I prefer different platform projects and maybe keeping the core code aligned as shared code between them. But that’s a completely personal preference.

36

add Console Apps into this and it is exactly what I am looking for.

I logged an enhancement a couple of months ago if anybody is interested.

<https://xojo.com/issue/38467>

37

design you app with external files

  1. Desktop GUI logic
  2. Web Gui Logic
  3. iOS Gui Logic
  4. common business logic

very few #IF would be required… but it would be a bit more “management”, but the bulk of the code would be in #4 where syntax would be “common”

38

I see at least a huge conceptual difference between desktop, iOS and Web. The first one uses windows, and that includes MDI windows for MS Windows. Web and iOS are page based. In Desktop, one would talk about kiosk mode. Not to mention using resizable window for Web and rotation for iOS. So if one was to design a UI for Desktop and want to generate a build for Web, how would it work ?

As it stands, logic can be used in the three (under the condition to use the new framework for iOS), so a module containing methods and properties can be reused without modifications.

I frankly doubt a common UI is possible, given the drastic differences between controls.

[quote=201711:@Kevin Gale]add Console Apps into this and it is exactly what I am looking for.

I logged an enhancement a couple of months ago if anybody is interested.

<https://xojo.com/issue/38467>[/quote]

Since a console app has no GUI, it is very easy to copy logic. But yet, once again, the conceptual difference between a line interface and a graphic one is so remote, and on top of it the necessity to create your own main loop in a console app, even a windowless desktop app and a console one are kind of alien to each other.

39

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.

40

Creating a table in Xcode Swift is quite easy… and while Michel says [quote]XCode is fantastic if you want ALL possibilities of the framework[/quote] this is not an incorrect statment, but you don’t NEED to utilize all the possiblities, just the ones you want/need… but at least you have that option, an option that the current version of XOJO for iOS doesn’t offer, without resorting to declares and such.

Now that being said, tables in SWIFT (or ObjC for that matter) are DIFFERENT, but different does not equate to difficult, it just takes time to alter your mindset, and if I can do it, anyone can :slight_smile:

my personal complaints against XOJO for iOS include (but not limited to)

  • missing fundamental controls
  • those controls that are there are missing many standard properties (borders, colors etc)
  • the use of DECLARES is more the rule than the exception
  • is two versions behind in the level of iOS supported (iOS7), so no support for LaunchScreen (just bloated Launchimages)
  • best I can tell use of Autolayout is mandatory… making it difficult to have the level of control sometime required. SWIFT at least allows you to use it or not use it, and my PERSONAL OPINION is to NOT use it