I hope that here I will find out more information about Oxygene. So, I want to make some interesting apps for multiple platforms, therefore I searched for proper solutions and the best ones are Oxygene and Xamarin. I have Pascal (Delphi) and C# background, anyway the two languages are quite similar (I feel comfortable with both). I have to tell you that I like very much Oxygene, how it works.
I compared it to Xamarin and the generated app size, faster app start was impressive. The Hello World app in Xamarin was 3 MB while in Oxygene a few KB, not talking about other similar projects where file size difference was bigger. The price is fair, $699 compared to Xamarin price ($3000) that is again a good point.
Anyway I want to know, how much can I rely on your products? I don’t want to invest money and time to learn something that would disappear in a few years. It’s true that code reuse is not so efficient compared to Xamarin solution (maybe Sugar will solve that inconvenience) and the fact that using Xamarin, developers write code in C# not Object Pascal (maybe C# in Hydrogene), meaning more chances to get a job (anyway not my case, I have my own business where I decide what we use - but I have to find developers who are comfortable with pascal instead of C#).
I have to admit that I like the concept of components in Xamarin, therefor making life easier when having to use some complex things. It would be nice to use them in Oxygene especially that Xamarin developers community is growing very fast therefore many interesting components appear each day (in case of Oxygene - there are not so many sample apps, anyway enough to understand how to use it). On the other hand it’s very good that third party components (ex: java code) can be used out of the box, without having to make those bindings like in case of Xamarin.
I would like to have a general picture in order to choose the best solution, that would fit my requirements like code reuse, fast deployment, file size, development language popularity, design tools, sample apps, component use, software updates and others.
Note that in your price comparison: our products don’t expire, even if you decide not to renew your subscription, the existing versions you have stay working.
We’ve been around for a very long time, and with Oxygene since 2005.
Oxygene can consume .NET, Java, android and OSX/iOS components without having to write any wrappers, and there are a lot of those components out there.
We’re always working on improving the samples and documentation (suggestions are welcome if there’s something specific you’d like to see). And of course, if you have any questions you’re always welcome here.
Anymore, the Xamarin licenses don’t expire either (see the last question here: https://store.xamarin.com/). However, that said, with Oxygene you don’t have to pay extra to use Visual Studio and it even comes with Visual Studio Shell! That’s a strong point in favor of Oxygene for me.
thanks for answers. Yes, you're right, the Visual Studio Shell thing is really a strong point. Anyway regarding Xamarin and Oxygene price, even if the license don't expire, the $3000 for Xamarin is more than anybody could afford.
In a blog post Marc mentioned about Hydrogene being a C# front-end. I’m waiting for this to become reality (I’ll find easier C# developers than Pascal developers), even if it will cost more than Oxygene. Anyway I don’t know when it will arrive (in a few months or a years). Should I start intense development in Oxygene, having a strong assurance that in the nearest future (not years) will arrive a C# version (Hydrogene) working similarly to Oxygene?
I also think Xamarin and Oxygene are the best solutions. The Xamarin’s advantage is you can use C# and the .net library. But it’s too expensive. And you have to catch up with their update. For example, the Xamarin.Android app crashed on Android 4.4 ART mode, you have to wait for their fix.
I think most of the current technologies are backed by a strong support concerning resources. The more expensive the product is the more likely is another scenario a product alive will be adjusted to the needs of a special good paying customer group or specialized for a specific industry. After a certain success in the early days companies sometimes start something different and they are very successful in the new area. If someone does offer products at a high price and you don’t feel comfortable with then you are very likely not the customer. That’s why I have given up expensive tools. This was required once but today a fair price for a straight solution does count way more than being part of an ECO system addressing the fortune n-hundred’s needs. Those are very different from ours very likely.
In case of Oxygene I don’t see that risk. I started with with Remobjects Chrome I think at the time of VS 2005 simply starting to get to know .net more closely and that beside my former daytime job. The whole thing worked out pretty well. There was never a period of doubt.
Sometimes decisions had to be done concerning priorities. RO do have a good feeling about what’s next, what’s required and what does make sense.
I think the Xamarin approach is the middle ground. When I first tried it I was quite impressed but whenever I wanted to do something I had to look at the documentation and then translate that to .net.
Since I was coming from .net I had a difficult time understanding not only the apple documentation but how I might translate the code.
The extensions made to oxygene make the translation much easier because api calls look pretty similar to objective C but only a lot prettier
Over the last couple of months I have used a couple of libraries off objective c libraries I found on github and its been a pretty painless process.
From my experience so far, Oxygen and the team behind it have been nothing but 1st class all the way. They’ve been responsive to simple questions as well as bug fixes. They really seem to be supporting the developer and not just the bottom line.
One original question had to do with code reuse. The only solution for absolute code reuse is the firemonkey approach. I tried it and hated it. It looks like they’re making progress in using more of the options available on native platforms but you really need to design separate front-ends for the apps if you want them to look like they should on the different devices. But, simulated controls don’t cut it in my book. So, after a while with the firemonkey approach, I quit.
I moved to Xamarin for IOS development. Well done if you want to follow the C# path but code reuse is still not there for the front-end. Then I still had issues with translation from the Cocoa libraries into C#.
I tried out Oxygene (had Chrome a long time ago but never left Delphi). It has been nothing but a pleasure to work with to create IOS and OSX applications. I’m currently planning on all my development to be converted to using Oxygene for Windows, Mac, and IOS development. Oxygene got it right! And I’m especially glad that the product is all in their hands.
Hi, thank you very much for your valuable answers.
DonaldShimoda - I also don’t like FireMonkey. I tried it and I wasn’t happy. It generated a huge package for a simple application that worked very strange, when I deployed it on my Android device (beside being a software developer I like electronics and I make software for microcontrollers where a 20 KB program can accomplish amazing things, this is why I’m so sensitive to app size ). Pascal coding is a plus for me, too.
mh - thanks, this is what I wanted to hear.Therefore I think you’ve got another client for your compilers meaning you convinced me that I should invest in your products. I hope the Hydrogene will work as smoothly as the Oxygen one. If these products will be advertised (to show that there’s an alternative to other development tools) more than you’ll get even more clients.
bmiller3 - there’s no 100% code reuse, neither on Xamarin side nor on Oxygene side, but if a tool allows me to make native apps, with small size, not having to ship I don’t know how many runtime dependencies, than I’m a happy developer (regarding other solutions with 100% code reuse - FireMonkey behaves very strange, generating big app size; the HTML5 + CSS solution dosn’t provide required quality and speed for products). The amount of code that can be shared between various platforms, depends on each developer, how he organize it’s code and what solutions he find for various problems. Anyway I need flexibility and I think I found it with Oxygene (I hope with Hydrogene, too).
Thank you very much again for all your help. I wish everybody all the best.
If someone does beat about the bush rest assured ideology is involved. Considering that counts more today than ever before. There is only one Pascal, the one that grew up in Delphi - sounds familiar;) Inquisition.
Indeed, Pascal developers do not run at risk to become part of a mass movement anytime soon. Being isolated does allow you to implement a solution that precisely matches a demand given. The other side of the medal is - a vendor can be aware that the customer working in isolation can simply become a victim to brain-washing. The brain washing does happen by simply keeping you involved, busy with the technology and the vendor being present. Always reminding you that you are now part of the community. Nothing specific about a certain vendor, that’s the current technology environment combined with the various marketing efforts.
The FM approach is about combining every ideologies basic believes the API calls into one universal view and offering a new one. Lord Castlepool in Winnetou. A strange figure hunting butterflies in every corner of the world but never adopting his habits. So it’s no surprise that changing the clothes will not make him a trapper but look as crazy as Tante (Aunt) Droll. Not a Trapper but wearing strange clothes.
Oxygene is simply about living with the fact that different cultures have found different ways to solve issues. Trapper. A trapper is in the position to survive by integrating into and making use of an environment. RO is about communicating with different cultures too accepting that those are different.
No one should be given the illusion of not having to cope with a certain environment. If you see a rattle snake you should know what it is and not have to look up in a book. Not being aware of the existence of serpents can kill a customer relation.
Be it XAMARIN, be it FM or whatever is put on top is about riding into the Valley Of Death (Valley Of the Dead). You ride for a while and all of sudden the vipers attack you from every side. In that situation it’s not wise to have to look. how do things work at the native API level and how could the issue be solved, did the designer of the library consider and if yes how, …
). Pascal coding is a plus for me, too.