Dalija Prasnikar

Installation support is free.

C++ Builder still has a long way to go to catch up with Delphi and probably even more to catch up with other C++ based tools. If you still feel like it would be better to use C++ Builder, go to QP and check all the bugs listed under C++ Compiler and C++ RTL to see if there are any serious showstoppers for you.

Just pick the most appropriate section according to the topic you are asking about. There are no too simple questions here 😉

Usually the fastest way to prepare device for debugging is to create blank application in Xcode and run it through its debugger. Xcode will take care of everything. If you also give that application same bundle ID as the real one you are making, Xcode will take care of provisioning profiles and all the certificate stuff. Once you have them, you will have Delphi iOS app up and running (debugging) in no time.

Yes. I think latest one I tried was iOS 12.3, but also tried all versions from iOS 10.

It turns out deploying and running works, debugging does not... (I am just relaying information I have gathered in the meantime, I still haven't tried myself)

Placing bets... it does not... I am not in the rush to try it myself.

Depending on how AnsiString is used, it can be replaced with RawByteString in cross-platform. Only if it interprets stored characters and makes conversions, it cannot.

Unless someone designed framework poorly. There is also possibility that framework is only for Windows and cannot be used as cross-platform solution. Still, people might use FMX only on Windows, so naming framework VCL would be poor choice in such case.

It's logic is mystery to me... it always chooses 26.1.1 for me and I have platforms from 19-28 installed. Why it picks 26 instead of 28?

Chances that it is false positive are about the same as chances you will get eaten up by black hole tomorrow. They need to fix their code. I gave you scenario (code) how this can happen, and something similar happens in their code.

If the things were done right in the first place we would not need workarounds.

Arghhhh... who designs this stuff? Some warnings can be setup at one place, other in another... it is a mess...

Reported as Unknown attribute can only be turned to error via compiler directive https://quality.embarcadero.com/browse/RSP-26208

Err... according to that there is supposed to be new warning so current behavior is fine, but I cannot see it nor turn it on. (except with compiler directives)

Please file a bug report.

You need at least 24 Nobody is detecting anything. Delphi IDE adds that automatically because you need to target at least API 26 (now 28) and Delphi does not support resizeableActivity (AFAIK) so it must explicitly set it to False. Default value if it is not explicitly set is True. Why it adds it after you save project and not before, that is another story.

That value 26.1.1 seems to be hard coded somewhere and is basically meaningless. What you need to do is go to SDK Manager, and under SDK choose appropriate platform folder: SDK API level location C:\.....\sdk\platforms\android-28

Well, then Android doc got it wrong 😉 https://developer.android.com/guide/topics/manifest/activity-element.html#resizeableActivity

android:resizeableActivity was added in API 24 if your target API or SDK platform is lower than that version that resource identifier will not be recognized.

If they add warning they could just as well fix it... Seriously, no matter how hard I try, I cannot figure out the real reason why...

Memory-Leak on Const-Parameter https://quality.embarcadero.com/browse/RSP-10100 Also specifically for ARC compiler, above problem can also cause crashes (linked with above report) Leaks or crashes on passing freshly created object instances directly as interface parameters https://quality.embarcadero.com/browse/RSP-17071

This is rather sad fact(s). Both that talking about bad coding practices is considered trolling as well as fact that after of decades of discussions and knowing that certain code is bad it is still widely used and all warnings are ignored. Embarcadero cannot possibly take in account every single line of code out there. Problem here is inherently in 'with' and not in adding additional functionality. Every change has potential to break some code somewhere, but with attitude that nothing should be changed we would have no progress. That does not mean that bad code changes will not happen. We are not discussing other languages here. 'with' is the problem within language itself. You can shoot yourself in the foot with 'with' even in single line of code. Again, main problem is that code may break due to far away changes you may not even be aware of. 'with' makes code fragile and prone to breakage more than it would be without it. Any code can be broken one way or another. Point is minimizing accidental and subtle breakage as much as possible. On this we agree. With every rule there are few exceptions. That does not mean we should not strive to educate about particular code dangers, especially when benefits are minimal or non existent and can be obtained by using different techniques.

We are talking about TRect here. Very basic type used all over. It is not very likely that one will create his own types for just about everything. And this is where using with can easily break your code without you even realizing it is broken. This is especially problematic when used in combination with UI where testing is hard and you can have a lot of code that is poorly covered with tests that could reveal such issues. 'with' is relic of another time and another coding practices. And, yes you could shoot yourself in the foot even back then, but now it is extremely easy to do so. Not using 'with' is the best advice one could offer. It is almost like using goto and absolute. You may have some very limited use case where using it is justified, but you will not find such constructs being used at large.

There is open report requesting App Bundles support. Anyone interested in Android please vote for it. https://quality.embarcadero.com/browse/RSP-25625