Why does my Android application, compiled with Delphi Rio, no longer work?

Variations of the above question get asked on a daily basis and there is an increasing number of bug reports that state basically the same thing. Android applications compiled with older Delphi versions work, and simply recompiling them with Rio produces a non-functional application.
Is Delphi Rio broken? NO. So what happened? First of all, mobile development regardless of the toolset is a fast moving target. New versions of mobile operating systems are released on a yearly basis, introducing new features and breaking old behaviors. Applications submitted to both the App Store and the Play Store must satisfy some minimal requirements defined by their respective owners. While Apple has always been pushing for faster adoption of newer iOS versions, forcing developers to stay current and compile their applications using newer SDK versions, as of recently Google has started doing the same.

Just like there is a minimum requirement for submitted iOS applications to use minimum iOS 11 SDK, G…

ARC is dead, long live ARC

First, forgive me if some of my thoughts seem a bit contradictory or confusing. My brain is still steaming... and I am not sure what to think...

Please, no...

What took you so long...


But before, I start rationalizing...
ARC IS NOT BROKEN, IT JUST NEEDS SOME POLISHING... I have been saying for a long time that the dual memory management model is not good in the long term and there should be only one memory management system, but by removing ARC in Linux compiler (10.3) and future plans to remove it from mobile compilers, I am afraid that Embarcadero have opted for the wrong one.

Yes, ARC in Delphi has some issues, but those issues are fixable. Manual memory management is an obsolete technology. It has some niche use cases, but for general-purpose programming, you don't want to waste time on memory management. You want to focus on the real functionality of your code.

To be fair, every memory management model has its strong and weak sides. Every one is more fit for some purp…

Catch Me If You Can

It is common knowledge that exceptions raised in some piece of Delphi code can be caught and handled with try...except blocks.
No matter what. try // here goes some horrible or not so horrible code // that can raise the most horrible exceptions except // no matter how horrible exceptions are // you will always land here where you can handle them, // eat them up and pretend they never happened, // or do something and re-raise them // YOU ARE IN CONTROL end; For example:
type TFoo = class(TObject) public procedure Foo; virtual; end; procedure TFoo.Foo; begin end; var Foo: TFoo; begin Foo := nil; try // calling a virtual method on nil reference raises an Access Violation exception Foo.Foo; except Log.d('CAUGHT'); end; end; Capturing and handling exceptions within try...except blocks is one of the cornerstones of Delphi coding practices. Millions of lines of code depend on that exception trap, from which ther…

Mysterious Case Of Wrong Value

Anonymous methods in Delphi give us two things.

The first is the ability to write method code inline - passing it directly as a parameter to another method (function/procedure) or directly assigning it to a variable of the appropriate anonymous method type.

The second one is the ability to capture (use in method body) variables from the context in which a particular anonymous method is defined. This is especially useful for various callback and task related patterns because we can standardize (simplify) method signature and still have access to all necessary data from the outer context. Simply put, for every variable needed to perform particular functionality inside the method, we don't have to introduce another parameter.


You decide to put together a simple piece of code to explore new possibilities.
uses System.SysUtils; procedure Test; var Functions: array of TFunc<Integer>; Func: TFunc<Integer>; i: Integer; begin SetLength(Functions, 5); for i :…

Delphi Community Edition

After extending Delphi PRO SKU with mobile platforms, more great news from Embarcadero!

The introduction of Delphi Community Edition (CE)
A free PRO level version of Delphi and C++ Builder targeting hobbyists, open source developers, small startups..., anyone that does not make more than $5000 a year from using it.

Since CE license is restricted to 5 or less instances on network, the Academic program is still available for training purposes.


LinksDelphi Community Edition Landing Page
Delphi Community Edition Download Page

C++Builder Community Edition Landing Page

C++ Builder Community Edition Download Page

Community Edition FAQs

Community Edition Eula

Community Edition Docwiki Page

Feature Matrix

Moving from Community Edition to other editions and moving from Starter to Community Edition

Delphi Memory Management - Paperback Edition Released!

Dear Gaia,
I admit. I'm weak. I caved in. Please forgive me!

I hope Gaia will accept my apology!

I caved in to popular demand and have released a dead tree edition of my book. The first prints just came from Amazon (.com not the rain-forest... not sure about the origin of the paper, though...), and the book is ready for sale in its paperback form!

You paperback lovers, you...

You can find several ordering options, from eBook (PDF, epub, Mobi, Kindle all together at $37.50), single license or multi-developer site license, to Paperback (via Amazon, $45) and the bundle of both eBook & Paperback (ePixEditions/FastSpring and Lulu, together $60).

You'll find all of this at:

Is it leaking or not?

Catching memory leaks on the ARC compiler can be a daunting task. Even if the destructor of an object instance is called, that still does not mean your object is completely released.
In the classic desktop compiler, a quick test to see whether some object instance was released or not was to add a breakpoint (or some logging code) into the destructor, and if you got there, all was good. This is not the case with the ARC compiler.

The last method called in the object instance lifecycle after which all instance memory will be completely released is TObject.FreeInstance. While this method is common to both ARC and classic compilers, on the classic compiler executing the destructor would inevitably (unless it throws an uncaught exception) mean executing FreeInstance and completing the release cycle. On the ARC compiler, there is no such guarantee. The destructor can also be called directly via DisposeOf, and FreeInstance will be called only after all strong references to the object are c…