I think we should continue with DeskTop and Web and when these both are perfect then think iOS
way no use all resources to complete DeskTop and Web (Mac,Windows,Linux,raspberry pi)
no more fights over who is better than who
I would like to be the first to congradulate Alexis on being promoted to XOJO Marketing Manager 
otherwise there is no “we” involved in those decisions… we are but customers, that sometimes have input that affects the future,
This will never happen, because both sides evolve. 
sorry
without disturbing anyone
what I mean is that fight for something that does not work well because we forget that and (we customer) focus on that if it works it’s Web, Desktop then when XOJO have the Resources can fix iOS.
I’m still waiting for weblistbox have the same functions as the desktop listbox this maybe easy the iOS.
But we all have different preferences. I would prefer to see a MUCH improved iOS support, because for my needs Desktop is already working fine. Most if not all current Desktop Issues my Projects hit, can be worked around or be solved with a 3rd Party Plugin. And that’s why i am sure, some of us would be very pleased if iOS would support Plugins. Now, not “then”. So we can implement our own Solutions, sell them or in my Case, buy them. 
+1
If only iOS could have a complement of commercial plugins with the typical quality of service provided by MBS, it would be a great step towards a credible product. Luckily, the very impressive dtPlugins are back, but for a while there was only iOSLIb and iOSKit which are nice, but no offence, the best open source individual effort cannot compete with a truly professional product and the service that comes with it. No more than MacOSLib can pretend to be better than MBS Plugins complete.
Granted, there are people who specifically refuse commercial products and for them, open source or snippets probably do. But for truly professional development, one needs top quality and top service, with instant and reliable results.
Indeed iOS plugins could make the difference between a toy, and something that can be used to create real state of the art apps.
I guess it’s me but without the x-plat benefits, I don’t understand why someone would use Xojo for iOS Apps instead of Xcode.
Is it because Swift is too difficult? Or Xcode is a beast to work with (well… I can understand that one). Or maybe the helpful forum or the documentation?
I can’t imagine it’s about the familiarity with Xojo code because with the new framework, things are pretty different.
And going through all the hoops with 3rd party plugins (and their own documentation) , declares or things that work different or can’t be done etc. you might as well pick up Swift/Xcode.
Swift is NOT difficult… its DIFFERENT, and “optionals” are a pain to deal with sometimes (is it ? or ! or neither)
Xcode as a CODE editor is also “not a beast”… it CAN be if you let it, what I find to be “a beast” is Interface Builder, as in I have yet to get anything there to come out like I want, so I do everything in code (including building the UI, which really is quite easy)
Xojo Desktop with MBS plugins, Einhugur and available third party tools combines fast development and access to the framework, which explains why I rather go Xojo than XCode for OS X apps. That, plus of course some 14 years of existing code.
XCode is slow, often cumbersome and paradox of choice incarnate. I spend more time going through all the options than actually coding. Plus Apple documentation, well, is not exactly ideal. All in all, developing with XCode is not at all as comfortable as Xojo.
Even with the new framework Xojo iOS has potentially all the qualities of Xojo Desktop : intuitive and fast development, and familiar access to events, properties and methods. If only it had true access to all iOS hardware (not a few and far apart more or less reliable declares), plus enough plugins to have true access to the iOS framework, then it can fly.
Note that I am talking about commercial plugins and third party tools, not declares. There is a world or reliability between the two. I can play with declares for fun and instructional pleasure. But when business is at stake, I rather go for a truly professional and well supported component. I would not repair my car myself before driving coast to coast.
I have long observed that most books about iOS usually pass Interface builder rather quickly to go straight to creating controls in code.
Personally, I am most comfortable with visual representations. Going back to paper in order to code controls reminds me of the old age of QuickBasic and AppleSoft Basic. Amazing how a company that prides itself in having the most user friendly UI can force developers to employ such outdated tools.
It was more meant as a question why people stick with Xojo for iOS Apps when there are no x-plat benefits. I personally find Swift extremely easy to use.
[quote]
Xcode as a CODE editor is also “not a beast”… it CAN be if you let it, what I find to be “a beast” is Interface Builder, as in I have yet to get anything there to come out like I want, so I do everything in code (including building the UI, which really is quite easy)[/quote]
From the few things I had to do with Xcode in the past, I found Xcode very difficult to work with. And you’re right, the Interface Builder is the main culprit.
I never have gotten that far to creating the UI in code. I will for sure look into that. Thanks.
The original question was, “Why Xojo instead of Xcode?”
Around a year and a half ago, I was convinced that I wanted to develop mobile apps. I spent a lot of time exploring LiveCode, Xcode / Swift, Xojo, and PhoneGap. I ultimately decided to go with Xojo.
From the moment I started using Xojo, I felt comfortable with it. I cannot say that about the other tools that I had explored. Xojo is a tool that perfectly fits my development style.
Also, I found the learning curve for Xojo to be very reasonable. Not easy, but not difficult either. It’s an environment and language that, to me anyway, is logical and straightforward. I truly enjoy using it, and it has renewed my interest in and passion for software development.
That being said, I’ve worked on several projects where I’ve had to use Xcode / Swift. I’ve used it to develop a number of iOS and tvOS apps. For the iOS apps, I had to use it because the projects required access to iOS functions that Xojo doesn’t support natively and where declares weren’t yet available, or because the app UIs were somewhat complicated. For the tvOS apps, I needed Xcode to develop the bootstraps for TVML-based apps, and in one case a pure Swift / TVMLKit app.
While I’ve enjoyed working with Swift, the language continues to evolve very quickly and it can be very difficult to keep up with all of its changes. I’ve found Xcode (and Interface Builder in particular) as well as the iOS APIs to be absolute nightmares to work with. I’ve spent a lot of time in the Xcode / Swift world, yet it still doesn’t feel remotely comfortable to me. I don’t think I could use those tools fulltime - at least not for very long. They’re just too frustrating to use.
Which brings me back to Xojo. After spending that time in the Xcode / Swift world and seeing what it takes to develop iOS apps with them, I’m even more impressed by what the Xojo team has been able to do with iOS. I’m anxiously looking forward to seeing what they come up with next.
[quote=269269:@Dave S]
Xcode as a CODE editor is also “not a beast”… it CAN be if you let it, what I find to be “a beast” is Interface Builder, as in I have yet to get anything there to come out like I want, so I do everything in code (including building the UI, which really is quite easy)[/quote]
Seriously, are you using Storyboards? They really are trivially easy to use, and I have never really had a lot of trouble with them. The preview while setting constraints is very very useful indeed.
I also agree, Swift is not a difficult language to learn and master at all. The extensive libraries, most still showing their NextStep and Objective-C heritage are pretty hard to master though. I still have to look things up upon occasion.
-Paul
Seriously… no I am not… as I said… I can’t get IB to do anything meaningful… Autolayout is unbelievable… I spent 4 hours just trying to create a storyboard with a line of text at the top, an image in the middle, and a line of text at the bottom… and there were so many “features” I could not get anything to make sense… and that would be a SIMPLE screen. Oh… I wrote code that that did what I wanted, and supported all the current devices and took me 20 minutes… (I can do it in 5 now)…
Nobody seems to create documentation that explains Autolayout in an easy to deal with manner… Its all “just do it”, not “ok here is an example, now click here, see that , do this…” where you can experiment and see how things effect changes. All I can get is colored boxes (and sometimes numbers) to appear, with no context as to what it means.
And since time is money, and the amount of time I have invested in AL has shown zero return on investment, I’ve moved on.
Seriously.
Ack - cheap trick. Doing stuff like that, line em up and do an command-a to select everything. Go to the right hand bottom on the screen, click on the triangle thing, and say reset to suggested constraints. For something simple like that, or even up to something moderately complex, it “just works.”
Of course, there are some caveats, such as it won’t automatically work for multiple screen sizes, but … it at least works. And you can setup for multiple screens in not much more time.
Of course, writing code works too. 
confused… isn’t that the “whole idea”??? What I was trying to do was create a “simple” LaunchScreen Storyboard (uh… LaunchImages are so 2012)
Developing iOS 8 Apps with Swift
Probably the best course to learn programming iOS and Swift. After that you wonder why you hated IB.
WWDC videos have been a great source of learning
They start as far back as 2011 or so talking in quite a bit of detail about how to use autolayout in IB
[quote=269288:@Dave S]Seriously… no I am not… as I said… I can’t get IB to do anything meaningful… Autolayout is unbelievable… I spent 4 hours just trying to create a storyboard with a line of text at the top, an image in the middle, and a line of text at the bottom… and there were so many “features” I could not get anything to make sense… and that would be a SIMPLE screen. Oh… I wrote code that that did what I wanted, and supported all the current devices and took me 20 minutes… (I can do it in 5 now)…
Nobody seems to create documentation that explains Autolayout in an easy to deal with manner… Its all “just do it”, not “ok here is an example, now click here, see that , do this…” where you can experiment and see how things effect changes. All I can get is colored boxes (and sometimes numbers) to appear, with no context as to what it means.
And since time is money, and the amount of time I have invested in AL has shown zero return on investment, I’ve moved on.
Seriously.[/quote]
This is way off topic I know but this makes no sense to me - creating the whole UI through code?
Stanford lectures have a whole lecture devoted to auto layout…
[quote=269302:@Eli Ott]Developing iOS 8 Apps with Swift
Probably the best course to learn programming iOS and Swift. After that you wonder why you hated IB.[/quote]
Thanks for that link (fyi, there is now an iOS9 version)
Although I have yet to start the course (in a few minutes)… I see nothing in the cirriculum that indicates an intro to AL, but we shall see.
Yes Patrick, so far none of my iOS projects have a storyboard, NIB or XIB in them at all, they all work quite well, and support every single I device that apple has yet to produce, and should the iPhone7 have a new screen size, I can update them all in about 2 min each (yeah I know, with proper AL, I wouldn’t even need to do that)… But I still contend that there are tons of things that AL cannot do (custom font sizes per device, totally different layouts (my iPhone4 screens usually have to look much different) etc. But this is not the place to discuss/argue these points. Allow me to finish this course, and perhaps my perception will change…