Dalija Prasnikar

On Windows, yes. On other platforms not so much. Android and especially iOS are just sitting and waiting for opportunity to nuke your app.

Not necessarily compiler, but RTL/FMX or other frameworks. Yes, there were some changes in compiler that may have influence, but such errors tend to have impact across all platforms. Now, it would be interesting to figure out what exactly is the problem.

Do you have any information about iOS versions used? At some point (around version 11) iOS became more sensitive to touching UI from background threads. I had small test apps built with Tokyo and Rio that were happily running on iOS 9.x and were instantly killed on iOS 11.x.

1. Because they have full control and can do with it what suits their needs the best 2. Dogfooding 3. They also have IDE for Mac - Fire (and that was first one they wrote - AFAIK when they started that project there was no VS for Mac) - Water is just Windows variant to prove cross-platform viability of their approach 4. Here we were talking about VSCode that fits nicely for some things (not VS), but still is resource hungry Electron app. I don't know about Water, but Fire is native Mac application - which means fast. 5. When it comes to VS itself and VS being so nice... I don't know. Last time I used it it was dog slow comparing to Delphi IDE (around XE time). 6. Having plugins for various IDEs can be nice and certainly is good place to start when you are just starting - but nothing beats fully dedicated IDE under your control.

I would suggest Git or Mercurial. Mercurial is a bit easier to learn and most of the time prevents you from shooting yourself in the foot. TortoiseHg works great and fast. Git is more powerful, but has steeper learning curve And I still have to find Windows Git client that actually works. On Mac SourceTree works fine, on Windows not so much - slow beyond description.

Using classes just for the sake of using classes can be nice exercise in futility. I have to admit that I haven't paid close attention to this post and I have been reading it rather superficially, so it is possible that I missed some piece. But from your original post I don't see any compelling reason why you should switch to classes. Especially if you don't feel comfortable with them and don't really see the point. Main advantage of classes over records is polymorphism. If you don't have the use case for it, then records will do. Also, one small note - you are holding your records in dynamic array, and those are allocated on the heap, not on stack. Only the few bytes of your global record holder would sit on stack. And overall, class based solution would use more memory than record based one. That does not mean that you should not learn more about the classes, but trying to learn on wrong use case will make things harder not easier. You should learn about classes with examples where they really show their advantage and then you will be able to understand them better.

VSCode is great tool. It has its downsides (being Electron app wasteful with resources) but I guess you can't have it all. It is far from being full fledged IDE for all purposes (and all languages), but it fits nicely into developer toolbox. As far as Delphi is concerned, it can fill some gaps in Delphi IDE functionality, and sometimes it comes as a rescue when Delphi bugs itself out. With OmniPascal plugin it will get you a long way in cases where code completion stops working in Delphi and there is a lot of code that is not RAD and does not include working with forms. I also like it for editing frame and form files, when I had to change something without Delphi IDE interfering. But the feature I like the most is its search capability with automatic preview of selected file so you can easily get more code context - no mouse clicks, just keyboard. I also sometimes use it to edit Java code (and xml layouts), when Android Studio has a bad day - which is quite often. Even more often I use it to write Swift code, because Xcode can be a huge PITA, too. Not to mention it has markdown preview - really handy when writing documentation.

Some people will just copy paste anything smile or no smile 😉

Just in case... What case? If construction of the form fails you will never hit Assert line anyway.

File feature request at Quality Portal an post the link back here. I know many that would find such switch handy.

Creating at run-time is pretty straightforward. You need Owner and Parent, and sometimes setting Align property. You can use any FMX control as those - or at least I have been able to use them without a problem. FFrame := TMyFrameClass.Create(AParent); FFrame.Parent := AParent; FFrame.Align := ... And that is it.

Eh... I completely forgot you can turn that off

.dsk file in your project root folder. It will open project in state you had when you closed it. If you had code view open, you will get code view, if you had design view you will get that. It also remembers last settings for each form. And first time it will show design view (at least that is the case for the last few versions).

Is Delphi Rio broken? NO.... Why does my Android application, compiled with Delphi Rio, no longer work?

Define usable. Yes, I am aware that different people will have different needs and not all bugs affect all people. And while there is a number of bugs that are still not resolved, I haven't encountered any really showstopper Android issues with Tokyo or Rio, regardless of the update number. What might be greater problem in this case is general direction of removing ARC http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html that would most likely happen in 10.4 release (as hinted in a linked blog post). If that happens that would be major change that could introduce bugs in both Delphi frameworks and your application code. While in the most part cross-platform code is also meant to run on non-ARC platforms, there are parts of the code specific for Android and/or iOS platforms where people were counting and using ARC. In any case, I assume that there will be open beta for 10.4 version, just like there was for 10.3, and that developers on active subscription will be able to participate and ship applications with that beta if needed. I know this is far from ideal scenario, but it is better that nothing.

No, they will not have less strict treatment. Google knows exactly how many applications are affected by this (they can easily analyze applications submitted to the Play Store), and with the exception of older Unity games, obviously there is not too many. Also, vast majority of Android applications don't have to worry about CPU support because they don't use (link) CPU specific code (libraries) and are written by toolsets that emit Android Dalvik byte code.

AFAIK you have to use your username instead of email, unless your email is also your username.

Dummy apps will not help in this case. Updates also have 64 bit requirement. At this point in time it is hard to say what is the right strategy, beyond making sure that you finish and polish your apps as much you can before the deadline. 10.4 is scheduled for mid 2019 so all should be good, but you never know.

@Rollo62 @Kryvich {$RTTI} directive has local scope. That means you cannot set it for whole project and have it applied on everything. If you want to remove advanced RTTI from RTL/VCL, you have to recompile RTL/VCL, which is what OP wants. As far as recompiling Rio RTL/VCL is concerned, I haven't tried to do it... so I don't know what are the problems and even less what would be solution.

You can file report at Quality Portal When you create new issue select "Documentation Bug" under "Issue Type"

If I had a dime for every time some "simple test code" ended in production... 😋

I am sure your users will appreciate reading default exception message they cannot comprehend. Of course, "There was an error" is not proper error message - but that is different discussion topic.

Yes, of course. The only time you don't want destructor to run is when you didn't write one and your record does not contain any managed fields that need finalization.

This can be a number of things including certificates. From my experience, the fastest way to fix this is creating empty application in Xcode with same bundle ID and run it with debugging on the device through Xcode. Xcode will automatically resolve all the issues. After that, restart PAServer and run your Delphi app.

Just released Mac Mini 2018 versions are all Intel based. No worries for now. But 2018 versions are far from cheap. 2014 are better choice for FMX.