The advantage of using the Xcode layout IDE is that your apps will not just look like native controls (like how fire monkey does it) but they will truly be iOS cocoa touch native controls. You are using the same libraries used by objective-c developers. So you can use example code and 3rd party Xcode libraries. Additionally, Oxygene will never lag behind in features by having to wait for new libraries to be built. That is one of the problems we had with Delphi and C++Builder that gave Visual Studio the advantage in getting new features to market sooner. I think it is pretty slick how RemObjects designed Nougat. Even if Oxygene had a layout designer built in that could somehow use the native controls and make the xib and storyboard files, it would still require a Mac to build the final .app file.
I just purchased Oxygene and can’t wait to get into development on all of the platforms. I have a couple of Mac options: Install XCode on my work-provided MacBook Pro or use my home-built Hackintosh. Has anyone had any experience with the latter? I don’t see why it wouldn’t work.
@bprothero: Not debating the merits of it. Just pondering the workability of it with a dev team versus cutting out the middleman and just using Xcode.
@Tkimball, I don’t see why a hackintosh wouldn’t work. I’ve used it on a VM of OS X just to play around with it while at home but I use a Mac mini at work for real development. I am new to the Mac and I am finding I like the Unix based OS more than Windows 8. So I plan to get a Mac for home in the near future as my budget allows.
@jpierce I understand your point and I have considered the same option of using objective-c as well and may for personal projects that I may only target for iOS. What is exciting about using Oxygene for the project here at work is that I will only need to write one set of code that may be shared by all three target mobile platforms without having to port the code to three different languages (java, c# .net and obj-c).
I have only done oxygene on Windows, but I don’t think “one set of code” will work. Although you can do some common business logic in shared code, all the other aspects would seem to be OS and toolset dependent. For instance, I make a Viewmodel for my Silverlight/WPF applications. And then use xaml binding for the UI. But on another platform, their might not be an equivalent of xaml binding so then you have to do some other pieces parts and somethine else to hook the code up with the UI.
So with the proper design, you might be able to isolate where things are different for the platforms, but I don’t think you can just have “one set of code” that targets all three platforms.
But you are right that at least we don’t have to deal with 3 or more languages in addition to the UI differences.
Xaml Bindings and Cocoa binding works pretty similar, for one — so that brings you Mac and Windows being able to use the same model, with a different view binding to it, for example.
But agreed, it’ll never be that quite simple — that’s just a fact. Though i sure wish certain other tool vendors wouldn’t try to sell people the impossible, setting everyone up for unrealistic expectations… 
I figured there would need to be some platform specific UI code. My hope is that I may be able to make it modular enough that the business logic and library files may be shared between platforms in a common directory. Then have seperate projects for the three platforms that have their unique UI files and supporting code that make calls to the common code in the control event handlers. In theory that should work.
I do have a question though… once I import in the filename.a static library and generate a .fx file; will I be able to use that for iOS, Windows phone and Android? Or do they require that the common library be compiled into another file format specific to that platform?
.a files are for Cocoa only. If you want to share code, that needs to be Oxygene, you cannot share imported Objective-C code to .NET or Java.
I believe there are .NET and Java versions of the same libraries from that company. So I would just need to include those built libraries? There is also Delphi source but when I tried to import it into Oxygene, it was so full of errors that I felt it would be more difficult to port over the Delphi code. Maybe that would be a better option afterall?
If there are .net and java versions of the same library, using those would be the best option, yes.