I know that the relationship between RO and Embarcadero has changed / is changing, and this may affect Delphi support in the future, but I would like to ask if ROSDK (and other applicable RO products) will support Delphi iOS applications using Firemonkey ? It could be that this will already work in some way, but I’m not sure what that is.
The next beta drop of our for Delphi products will add official for Delphi XE4.
At this stage, we have no plans for supporting Delphi/iOS. This has little to do with out relationship with Embarcadero, but more with the fact that Delphi/iOS is — despite what the marketing is trying to tell you — a radically different language and compiler from the Delphi you know, and supporting it, at this stage, essentially would mean forking the code base.
We already maintain five (!) different versions of the SDK and Data Abstract, each designed from the ground up for the respective platform (and we would not want to have it any other way). At this stage, we do not feel it warranted to add a sixth, when we already have iOS development well covered with our fully (one could say, “true”) native “for Xcode” edition (which is not really specific to Xcode but will work with any decent OS X/iOS compiler tool chain — in fact we’re abot to rename this edition to “for Cocoa” with the next release).
Only on top of that comes the fact that we believe Delphi/iOS is a step in the wrong direction; we don’t believe it will see wide adoption by Delphi users once they see the results and limitations f this approach, and we’re not sure we want to encourage customers to walk down this path by actively supporting it.
I hope this makes sense, and thank you for understanding.
—marc
Hi Marc
I fully understand. I am currently making decisions about what direction I should go regarding mobile development, and am highly likely to go with Oxygene rather than Delphi, which is a HUGE decision as I have been a Delphi user since v1.
This news will probably help me make that decision.
I want to create applications under both iOS and Android, and while Oxygene offers a lot of code compatibility, there are some areas where there is significant incompatibility. For example under Oxygene for Java there is no support for unsigned integers. I know that this limitation codes from the Java runtime, but it really does cause huge problems. If a way could be found to work around this limitation it would greatly simplify things.
Unsigned Integers are coming to Java 8, and we’re looking at adding them to Oxygene as well (for sure if they do come to Java 8, possibly even if they don’t). You’re not the first to raise concerns about this being a problem, so we’re very aware of this (and in fact i shall raise this for internal discussion again, whether we can add support for them sooner that Java 8)
Thats great news. Bring it on !
Hi Marc,
apart from FireMonkey iOS (who is happy with it should use it).
For my part, I am trying to learn Nougat first.
But EMBT has also threatened that “Delphi for Windows” will be converted at some point even to a LLVM compiler.
Is there a danger that you will “push back” the support for your products and this happens?
Without Firemonkey iOS I can live well, but not without VCL and ROSDK.
Data abstract I would also miss here and there …
Nougat makes a really good impression. I love it, although the learning curve is pretty steep for me as “old Delphi VCL developer” (without great Mac/iOS experience). A few more beginner videos from Jim would be fine … 
Best regards,
Jens
Ouch, these are terrible news. I hope with time things will change, we are very motivated with our initial testings on DX4 and not being able to use it on mobile will definitely put us in a rough spot.
We were moving from DataSnap to DataAbstract, these news will definitely put everything in perspective. It is a fact that Embarcadero/Delphi will move to their new compiler, by the end of this year they will have Android and I don’t see too far moving their current compiler to LLVM, it just makes sense and allows them to target many architectures.
I will expect updates sooner than the current yearly ones, so I will not be surprised that in a matter of two years Windows Delphi will be on LLVM.
The current decision means basically the dead of DA on Delphi. I hope these changes, cause I really love DataAbstract.
We’re committed to supporting Delphi in the desktop. If and when the new compiler comes for Windows, we will review what needs to be done support it. For now, that seems to be quite far off, and it’s premature to speculate what kinds of language changes it will force on us (and you), and how to deal with them.
I have to agree with estebanp. Forward thinking Delphi developers are looking for the ability to write code once and reuse existing code to compile to multiple target platforms. I like RemObjects and don’t want to use Datasnap, but if RemObjects will not support such a critical direction in the evolution of Delphi, what choice do I have? Can you please be more specific and justify the following statements: “radically different language and compiler - Delphi/iOS is a step in the wrong direction - results and limitations of this approach”. How can Delphi/iOS be a step in the wrong direction? The demand for Delphi iOS and Android based clients will only grow - how can it not? EMBT are not without their faults but it does look as if they are moving in the right direction to take Delphi into a cross platform and multiple device future. A Delphi future without quality component suppliers like RemObjects would be a real disappointment.
“radically different language and compiler”
Two off the top of my head:
- zero-based string indexing
- no mo AnsiStrings, just one Unicode string type
these are not bad things for a language per se, but they are terrible things for backward compatibility — it essentially means a fork in the library, or excessive and unmaintainable level of IFDEfs. Especially since we’re still supporting pre-unicode versions of Delphi as well. (This clearly is a move deliberate by Embarcadero to force third parties hands to drop compatibility with older Delphi versions and force them force their customers to later versions.
“is a step in the wrong direction - results and limitations of this approach”
‘write once, run anywhere’ has been promised for decades, and never worked. It didn’t work for Java, it didn’t work for Kylix, and it wont work our for FireMonkey either. You cannot properly target different operating systems without properly designing for them and using their native ui controls.
“How can Delphi/iOS be a step in the wrong direction”
your blind trust in what Embarcadero is doing is touching, and i’m sure they appreciate it.
“A Delphi future without quality component suppliers like RemObjects would be a real disappointment.”
as mentioned before, we are committed to supporting Delphi, including Delphi XE4 and beyond (the current beta has XE4 support, and so will the next release). We’re just not supporting the iOS target at this stage, because — as i laid out before — we don’t believe it’s a good solution, and we don’t believe there is sufficient demand to warrant the amount of work and technical debt that supporting it is going to introduce.
I do not have blind trust in anything - hence my request for more facts to justify your negative comments about Delphi/iOS. But thank you for taking the time to share your views - although I do not necessarily agree with all of them. At least I get a response from RemObjects.
I don’t blame them on wanting to cut off their tail. Delphi has maintained an unbelievable backwards compatibility that many got very used to it but make the language slow to evolve.
Oxygen drop VS2003 and I will expect VS2005 to go out soon, I dont see the point on maintaining a strict compatibility with anything 6+ year old, specially on this industry.
See it this way, RO SDK has a “not that good” backwards compatibility. Most solutions to problems are deferred to “it is fixed on the latest RO” which implies upgrading and maintaining our subscription up to date. I can’t blame Embarcadero for finally catching up on the ride that everyone else is doing.
I don’t mind ROs approach to wait and see, but knowing that EMB is putting tons of cash and effort on FM and LLVM it is an unavoidable future that Delphi is going on that direction. But waiting for stability, is a wise choice.
i’m all for shedding needless backwards compatible where it makes sense. changing string indexing does nothing to bring you forward, and everything to kill any chance of backward compatibility.
As for ‘nextgen’ Delphi being “unavoidable” — i don’t think so, though Embarcadero is clearly banking on everyone believing it is. 
Please no more platforms:) at the moment.
- As for ‘nextgen’ Delphi being "unavoidable"
Thought about this. In practice it’s a must. But as Sebastian pointed out wisely - Einheitsbrei.
There are so many things that have to be improved (not talking about fixes) even in the area of traditional VCL/RTL too. The Delphi XE4 IDE with minimum CodeInsight features turned on is almost rock-solid. I personally prefer Gendarme and such nice helpers but it’s not a must.
64bit Windows debugging on a remote machine - improvement yes - you can save the project and shutdown the IDE safely. One time access the Text property of a TEdit the whole debugging session is lost. On the other hand viewing complex structures works - debugging is somehow convenient unless you move with the mouse over the ‘wrong’ expression a show a tool tip tries to show up. Disconnected - thank you. With OS/X 32-bit remote debugging works missing 64-bit, ODAC works good using wire protocol. But try to bind data to TEdits via not deprecated bindings and try to format values in FMX TGrid - in a universal business application framework numbers are left aligned in a grid? I made it work, but that’s cumbersome.
There are so many dependencies on COM … start a Delphi webservice (just client) call a remote function in a separate thread. You need to call OLESynchronize first otherwise MSXML is not found. Try to find the cause of this exception if you don’t know the special treatment of interfaces in Delphi …
Implement an anonymous thread, forget a semicolon and a wrong error message is shown paragraphs below. Not talking about web-services and Delphi in general.
This was my sunday afternoon. The ice-saints came to town so I gave XE4 a try and tried to make something usable in practice. Oh! And I forgot that about 1 bio graphic cards would have to be updated to have a reliable deployment base for FMX apps on Windows.
There are tons of such details. Try to access the certificate store on Windows in a C like fashion if you don’t want to be bound to the result of the TLIB import … ActiveX has proven to be a reliable alternative on the Mac over decades now?
I think we talk about XF2 … and not XEx, when talking about a usable alternative on the desktop outside the traditional VCL.
Wondering how to implement a single source communication back-end for IOs, Android apps in Delphi running on Windows, Linux and Mac considering PKI infrastructure … cross-platform on one codebase is wishful thinking.
Similar to security - a goal many people dream of but unreachable in practice. Apps are inspired by web design … the web freed the computer from grey and humans are drilled to favor the visual sense over the others…
Let’s wait and see.
Just upgraded to 7.0.69, very sad, I hope RO SDK can support DELPHI / IOS, began to select RO SDK because of fast development, Do you want me go with RealThinClientSDK, or go back to DataSNAP
Although DELPHI / IOS is not the best, but there DELPHI / ANDROID, enterprise database applications quickly achieve cross-platform, DELPHI also a good choice
would love to see RO SDK for Delphi iOS, may have to switch back to datasnap or go RTC as exdsoft - don’t want to though.
I would be happy with only the client side of RO SDK for FM.
We’ll keep reviewing this, depending on what kind of traction FMX/iOS will gain. As of right now, all the original arguments against this still stand, and (to reiterate) we already support iOS via two separate libraries — Xcode and .NET. We don’t really have the resources to support every platform in 5 different ways.
I’ve being thinking about this. The Delphi branch of Data Abstract and RO seems to be only on maintenance mode, if the subscription will only get me an updated installer to the latest Delphi version and bug fixes of eternal issues then it definitely loses its value.
I’m sure that RO will add more stuff to their other branches but what is the progress or value for the Delphi users if RO is in clear conflict with supporting current and future functionality. I think a Roadmap is important at this point.
Something to think about definitely.
It was always difficult to “have more than one bird in the hand”.
Or think "that encompasses much and squeezing little"
So I do not lose the opportunity to continue making money in wanting to leave out such strong language and important for its history: Delphi.
I started programming in 2003 with Delphi, then came. Net in 2009 and is now complete chaos … (Java,. Net, Android, XCode) …
As an independent software vendor, use Delphi (Clients and Server) and. Net (Clients). For the times we live in, I started to develop for Android with Eclipse (Clients) and still nothing with XCode.
But I can not lose every chance to win. Same with RemObjects Company …
Do not lose customers to abandon or support the development of tools for different business environments.
If RemObjects does not have enough resources to maintain five frameworks, “we are in the oven and we’re starting to burn …”.
RemObjects Software, are incredible and support them in what they do … but do not lose the thread …
Do not give up the bases …
Do not lose customers …
I am brand new with you since August 2012, do not cut my legs …
I want to continue walking with you …