Sherlock

According to this https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Using_SQLite_with_FireDAC a download of SQLite DLLs is not necessary. You did provide a 64Bit DLL and your application failed. 32Bit without external DLL on the other hand ran smoothly. So....get rid of that new thing.

Please read my post carefully, I answered @JohnLM. Your frustration is valid. I have felt it more than once myself.

Now gee, what do you expect? How many of your clients demand to run your software on their outdated, unsupported and insecure operating systems (Windows 98 SE was sweet)? And what do you tell them? Even Microsoft has abandoned that product. Seriously, as long as you are using Windows 7 you will get nothing but sympathetic nods as every little issue could be blamed on the fact you are trying to run it on an OS that does not meet the requirements. Nevertheless 11.3 is the current version, so some of your issues may have gotten fixed.

Or if you use GExperts anyways, use the "Replace Components" expert.

I don't think signing is the issue. But consider the sometimes simple heuristics of a virus scanner: DLL = suspicious, file access = suspicious, compiled with Delphi = suspicious. That will generate a warning anywhere... not that its OK, but it is understandable.

Since FMX components have no hints altogether you'll need to program them on your own. Or look into our german site https://www.delphipraxis.net/169747-brennende-hinweise-fmx-hints-thintmanager-1-3-a.html. Alternatively you can go the way of the accepted answer from here: https://stackoverflow.com/questions/22417565/is-there-any-way-to-add-a-hint-or-tooltip-with-firemonkey Keep in mind however, that hints or tooltips are not something common on mobile devices!

It behaves strangely when resized: On a side note, the __Build_Project.cmd enters an infinite loop when run from a UNC-path like \\Mac\Home\Documents\Embarcadero\Studio\Projects.

Was it a problem with connectivity? We have a Mac Mini in our network, for signing the mobile apps. And we can use it to run the apps in the iOS simulator as well. Works pretty good. I have no Android experience on the other hand.

In that case I do hope you use that single out of the box method provided by Embarcadero to do that one line of calculating you need, otherwise someone might be inclined to call your solution a hack... just saying. The VCL framework like most other frameworks provide methods that should suffice for a very high number of use cases. But not all of them, this is to avoid feature creep, and other mishaps. Programming is not always straight forward. Sometimes you have to get creative. That is the reason I love it.

There is a "What's coming" webinar on November 9th so it is still roughly a month away.

Next time, perhaps consider using a VM. Snapshot before the update and, if it fails, just revert. Easy peasy nice and breazy.

What is it wasting? Seriously.

Great work! I'm guessing you zoomed away from the object inspector on purpose, because you are not quite done yet? It would be great to see what's happening there otherwise.

Or Zip with AES encryption...

The larger is a debug build, the smaller isn't. Why the debug build does not run as expected, whereas the release build does, is just a matter of checking the different build settings.

Yeah, Embarcadero sometimes fights with their servers. They'll come around eventually. I guess Delphi 12 is lurking, and the servers are being prepped for it.

Now there is the rub! A 64Bit IDE will be experimental at best. Quite the contrary to a stable IDE. Just consider the introduction of DelphiLSP. Now that Baby started birthing more than three years ago, and it is still not "robust". I'd prefer them to fix the 32Bit IDE to reach a robust stage over them pulling resources to that new construction site.

Lets say...sub par 😄

@GringoStarr Please refrain from posting the same question in different subforums for your own benefit. It will just divide attention.

Well, the main reason on the Embarcadero side would be that the IDE in its current state is not generated from on single codebase in one single language, but is a patchwork of more or less pretty quilts assembled to look like a single piece of software. Some of those patchy things have not been touched in quite some time (this is just a guess on my part, but it is an educated one). Lazarus on the other hand is dogfooding at its best.

To be honest, that is also the only driving force behind change requests (language XY has it) as well - hyperbolically speaking.

Sorry, but that wont do to run the simulator. It is ARM only - meaning you'll need Apple Silicone to run it.

Have you tried running your App in the simulator?

Slow your horses folks. Let's keep it clean and neutral.

Surprisingly (or not), this argument leads to spending more time with legacy code over time than rewriting from scratch. At least that has been my observation for the past 20 years.