I just had my Debt Blaster app rejected by the Mac App Store after six days in review.

It is built with Delphi 11.3 / FireMonkey.

Apple rejected it under 2.1.0 Performance: App Completeness (macOS) and said:

The app exhibited one or more bugs that would negatively impact App Store users.

Bug description: We were unable to use the core feature, because when clicking on any field, app UI gets covered by random boxes.

Apple tested it on a 14-inch MacBook Pro running macOS 27.2.

Their screenshots show the UI looking dramatically oversized, roughly 4x the size I normally see, with large gray/white rectangular areas appearing over the interface after clicking into fields.

The exact same build works correctly on my Mac mini connected to a standard 1920x1080 non-Retina display.

The submitted app has:

NSHighResolutionCapable = true

That has me wondering whether this is an FMX HiDPI/Retina rendering problem.

I found this older DelphiPraxis thread describing severe FMX scaling/rendering problems with NSHighResolutionCapable=true, where setting it to false reportedly fixed the issue:

https://en.delphipraxis.net/topic/2729-nshighresolutioncapable-true-scaling-problems-on-macos-1013/

Embarcadero documentation:

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Version_Info

Apple High Resolution documentation:

https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

I am now preparing a controlled test using the exact App Store binary Apple reviewed:

• Test A: NSHighResolutionCapable=true
• Test B: same app, same executable, same entitlements, but NSHighResolutionCapable=false

Both will be signed and notarized, then tested on the same Retina MacBook Pro.

Before I go further, I would really appreciate hearing from anyone who has shipped Delphi FMX macOS apps:

• Have you seen this type of rendering corruption on Retina/HiDPI displays?
• Have you used NSHighResolutionCapable=false in a production Mac App Store app?
• Are there known Delphi 11.3 FMX issues with Retina scaling that I should be looking at instead?

I’v attached Apple’s rejection screenshots because it shows the problem much better than I can describe it.

Hey Delphi folks 👋

Got a few quick brain teasers for you. No compiler, no Googling, just gut feeling 😏 Drop your answers in the comments and I'll post the real ones tomorrow.

1) Exit vs finally

function Magic: Integer;

begin

Result := 1;

try

Exit(2);

finally

Result := 3;

end;

end;

What does Writeln(Magic) print? 1, 2 or 3?

2) The object that never dies

type

TFoo = class(TInterfacedObject)

destructor Destroy; override;

end;

destructor TFoo.Destroy;

begin

Writeln('Bye!');

inherited;

end;

procedure Test(const I: IInterface);

begin

end;

begin

Test(TFoo.Create);

Writeln('Done');

end.

Does "Bye!" ever show up?

3) Good old "with"

var

P: TPoint;

X: Integer;

begin

X := 0;

P := Point(0, 0);

with P do

X := 42;

Writeln(X, ' ', P.X);

end.

What's the output? (If you love "with", you might not after this one 😅)

4) Negative math

Writeln(-7 div 2, ' ', -7 mod 2);

Python people, please sit this one out 🤫

5) Poor little Byte

var

B: Byte;

begin

B := 255;

Inc(B);

Writeln(B);

end.

Default project settings. Exception, 256, or something else?

Be honest about how many you got without cheating 😄 And if you've got a nastier one, share it. Maybe it'll show up in round 2!

Hi,

I just published the Python4Pascal project at GitHub.

Python4Pascal is based in the Python4Delphi project made by Kiriakos Vlahos (PyScripter).

It uses Python 3.15, 3.14, 3.13, 3.12, 3.11 and 3.10, and it supports Windows, Linux, macOS and Android.

Python4Pascal was developed and tested on Delphi 13.2, Delphi XE2, Delphi 7 and Lazarus 4.8/FPC 3.2.2.

The most important Python4Pascal features:

• Supports the latest version of Python 3.15
• Python4Pascal handles the Python objects lifetime automatically.
• Fully documented in XML code comments, CHM and HTML files.
• Imports more than 1200 Python library functions and types.
• Includes many helper classes to handle all Python objects with Delphi/Lazarus types as arguments whenever it's possible.
• Demos for Windows , Linux, macOS and Android.
• It's possible to create Python modules and module extensions.
• Python4Pascal can handle Python objects with variant types or using Delphi wrappers.

Python4Pascal has a few things in common with Python4Delphi but many other things are much different. Some Python4Delphi features are not included, for example RTTI and the assembler code to convert the callbacks.

I still have to write some tutorials in the Wiki.

I have posted two updates to my Codebot Library that now include IDE theming and Windows Shell controls packages:

Themes allow Lazarus to be altered using a JSON file to add custom styling and fonts to the IDE. It works on both Windows and Linux. Windows shell brings a selection of controls and components for replicating Windows file explore in your Lazarus applications on Windows. It is based on my old Codebot shell library, but bring about many improvements.

Brief videos are hosted on the two pages above demonstrating these packages.

I also have a dynamic package supporting FPC and Lazarus available for download that includes all these features and more, along with dynamic package loading and unloading.

And 26 bugfixes: https://www.steema.com/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&chfield=resolution&chfieldfrom=2026-05-27&chfieldto=2026-10-19&chfieldvalue=FIXED&list_id=11011&order=Importance&product=FireMonkey%20TeeChart&product=VCL%20TeeChart&query_format=advanced&resolution=FIXED

Delphi should have a personal edition for under $100 with a perpetual license and commercial use allowed for individual developers.

Some people just want to build native desktop applications with a visual designer without spending a fortune.

When .NET WinForms and WPF are free Delphi's pricing makes no sense. I know there's a Community Edition but its restrictions aren't a replacement for an affordable license.

What exactly does Embarcadero gain from this? They're just pushing potential developers toward other tools and once those people move they're unlikely to come back.

Delphi is still a good development environment, but its pricing and management seem stuck in another era. It's hard to grow an ecosystem when you make it so unattractive for new developers to join.

🏛 Delphi Forever! Get Your Free Delphi Deep Code Analysis for Total Clarity and Regulatory Peace of Mind!

🏛 Don't Panic! Even if regulators are knocking on your door with strict SBOM, CRA, and DORA compliance mandates - and traditional scanners don't even understand native Delphi code - your legacy stack is saved.

🏆 Stay Strong! Your Pascal code, your VCL 3rd-party components, and Delphi’s blazing-fast binary execution still work remarkably well. You shouldn't have to abandon the core tech that powers your business.

🥇 Service to the Delphi Community: Unlike vendors driving up subscription fees, we are offering our Analyzer for FREE to the global Delphi developer community.

🔥 Full Deep Scan with Zero Code Limits: Deeply analyze your compiled Delphi binaries, exposing all hidden DCUs, DLLs, embedded resources, and binary footprints regardless of project size.

🔍 Uncover the Blind Spots: Visually map statically linked C object engines (.obj), embedded resource payloads (.res), database drivers, and runtime "LoadLibrary" calls executing in process memory.

💥 Expose Hidden CVEs: See exactly what traditional source-code scanners (SAST) miss inside the native wrapper engine.

✔ No code limits.
✔ No analysis depth caps.
✔ No subscription fees.

👉 Keep calm & keep coding in Delphi, and let us cover your back beneath the hood.

Download your free Delphi Deep Code Analyzer today (link in first comment)

[ Removed by Reddit on account of violating the content policy. ]

💡 Have you ever wondered why there are almost no CVEs listed for Delphi or its 3rd-party components?

💡 Or why a Delphi app works flawlessly on your machine, but suddenly fails at a client site until you install OpenSSL, MDAC, or database drivers?

🚀 The answer is simple: Delphi is a high-performance wrapper engine.
What made Delphi's RAD legendary - and gave it sub-second build times - was its ability to stitch pre-compiled C object files (.obj), dynamic DLL wrappers, ActiveX controls, and Windows OS APIs directly into RAM.

☢ In the 2026 security era (CRA, DORA, SBOM compliance), this exact strength creates a massive visibility illusion:

☢ SCA Scanners are Blind: Standard tools scan .pas files and miss pre-compiled aes.obj or zlib.obj binaries statically linked via {$LINK}.

☢ OpenSSL Hidden Risks: Switching from Indy (libcrypto.dll) to THTTPClient shifts your security exposure from a bundled binary risk to an OS SChannel baseline risk.

☢ Invisible Payloads: Embedded .res files, $I include directives, and dynamic LoadLibrary calls sit outside traditional unit-level audits.

⚠ If you’re measuring your Delphi software supply chain by .pas and .dcu source files, your SBOM is an illusion.

Anyone seeking real security rather than regulatory compliance must deconstruct the executable from a bird’s-eye view.

👉 Read the full deep-dive on my blog: The Tombs of Delphi — The Hidden Supply Chain Uncovered – The Delphi Parser

After a summer spent on other projects, I've released version 2 of DX.Comply, an open source SBOM generator for Delphi. A lot of the changes come straight from user feedback, so thanks to everyone who reported issues.

Why it matters: the EU Cyber Resilience Act will require an SBOM for software sold in the EU. DX.Comply builds one from your actual build data (the linker MAP file, linked runtime packages, DLLs loaded by your code, files in the output folder), not just from what is listed in the project.

What's new in 2.0:

- CycloneDX 1.6 (JSON/XML) and SPDX 2.3, with the BSI TR-03183-2 fields

- Each unit as a component with SHA-256 and SHA-512, plus where the evidence comes from

- Dependency graph and a completeness statement

- Warnings for data the CRA expects but is missing (manufacturer, contact, version, license)

- Library mode for source-only libraries and component packages

- IDE expert for Delphi 13, plus a command-line tool that works back to Delphi 7

It's free (MIT), needs no account and runs fully locally.

Product page: https://www.developer-experts.net/en/dxcomply

The update should appear in GetIt shortly.

I'd really like to hear how it works on your real projects, good or bad.

Easy way to split a chart in four labelled zones.

Example:

https://github.com/Steema/TeeChart-VCL-FMX-Samples/tree/main/VCL/Tools/Quadrant

Hi everyone!

I've worked with Delphi for many years. Recently, I developed three IDE plugins to solve some everyday frustrations. All three are free, open source (MIT license), and support Delphi 11, 12 and 13, including the 64-bit IDE in Delphi 12 and 13.

To install, download the release ZIP, extract it, and run Install.bat. No administrator rights or compiler required.

1. CS.Coder Project Hub (Stable)

A project organizer built into the Delphi Welcome Page. It lets you:

• Group project shortcuts by client, system, or any category you choose.
• Add icons, search by name or path, and organize entries using drag and drop.
• Export and import the shortcut list as JSON.

It works alongside Delphi's Open Recent panel without changing it. It never moves or deletes project files; it manages shortcuts only.

GitHub: https://github.com/cscoder69/delphi-project-hub

2. CS.Coder Unit Styler (Beta)

A configurable formatter for uses clauses. You can choose one unit per line or multiple units per line, sorting, indentation, priorities, and groups such as System.*.

• Run it on the current unit, open units, or an entire project.
• Preview the before/after result and confirm before applying changes.
• Back up each file before modifying it.

Because unit order can matter, library namespaces (Winapi.*, System.*, Vcl.*, FMX.*, Data.*) are protected from reordering by default. The formatter is designed to preserve comments, compiler directives, encoding, and line endings.

GitHub: https://github.com/cscoder69/delphi-unit-styler

3. CS.Coder Block Folding (Beta)

Adds folding for blocks inside routines, beyond Delphi's built-in routine, class, and region folding.

Supported structures include if/else, for, while, with, try, case, repeat, and standalone begin..end blocks.

Press Ctrl+Alt+B to fold or expand the block at the cursor. It doesn't insert {$REGION} directives or modify your source. Folds exist only in the editor while the unit is open.

Current limitation: its menu and settings are available in Portuguese only.

GitHub: https://github.com/cscoder69/delphi-block-folding

Documentation (Portuguese)

• Project Hub: https://www.cscoder.com.br/projetos/hub-de-projetos-delphi/
• Unit Styler: https://www.cscoder.com.br/projetos/unit-styler-delphi/
• Block Folding: https://www.cscoder.com.br/projetos/block-folding-delphi/

A few important notes

• Unit Styler and Block Folding are in beta. Please use version control when testing tools that interact with source code.
• No telemetry, network access, or account. Settings are stored locally.
• Claude Code helped extensively with implementation. I defined the requirements, made the design decisions, and tested the plugins inside the Delphi IDE. The source is available for review.
• These projects are independent and are not affiliated with Embarcadero.

Feedback, bug reports, and suggestions are welcome. If something doesn't work in your setup, please open an issue in the relevant GitHub repository and include your Delphi version and IDE architecture.

Thanks for reading!

SweetControls is a collection of native Delphi VCL components for Windows applications, including edits, buttons, panels, lists, tree controls, database controls, and design-time editors.

The source-codes have been ported from Delphi 7 to Delphi 13.1

PolywickStudio/SweetControls: Sweet Controls VCL ported to Delphi 13.1

Designed specifically for the enterprise Delphi ecosystem, our platform delivers end-to-end regulatory compliance, deep static code analysis, and automated noise reduction - ensuring your applications fully satisfy CRA (Cyber Resilience Act) and DORA (Digital Operational Resilience Act) mandates.

Deep Code Analysis for Complete SBOM Generation - The only deterministic, AST-based dependency parser built specifically for native Delphi source code. Ignores environmental noise by evaluating compiler directories, decompiling compiled .dcu files, separating source code into local, system, and 3rd-party libraries, and performing deep-dive analysis to locate outbound ActiveX/COM, DLL, and Command-Line (CMD) calls.

Multi-Source Delphi CVE Intelligence: Direct PURL/CPE mapping with real-time aggregation from top vulnerability databases (including NVD, OSV, OpenCVE, GHSA, and others), tailored specifically to eliminate false positives from native Delphi components.

Centralized & Local Security DB: Aggregates and indexes a dedicated security database- available via a central cloud server or as a local offline database for air-gapped enterprise environments - mapped directly to Delphi components, VCLs, and native C/C++ wrappers.

Automated Non-Delphi Noise Reduction: Automatically filters out ~99.9% of non-relevant security alerts (such as Java, .NET, Linux-only, or non-native threats) before they contaminate your compliance reports.

Auditor-Ready SBOM & VEX Generation: Automatically produces clean CycloneDX SBOMs paired with machine-readable VEX (Vulnerability Exchange) JSON files containing precise not_affected and code_not_reachable justifications required for European regulatory compliance.

Immediate Vulnerability Reachability Relief: When a CVE is identified, the engine instantly and automatically validates reachability against an updated Call-Graph of your Delphi codebase - including outdated DLLs, OS calls, ActiveX/COM, and Command-Line execution paths - verifying whether the vulnerable code is actually reachable and executed in your application.

Up-to-Date Call-Graph & Reachability Reporting: Maintains complete visibility with every commit by automatically rebuilding up-to-date SBOMs, Call-Graphs, and Reachability reports across your development lifecycle.

Flexible CI/CD & Pipeline Integration: Seamless execution across local developer workstations, build servers, and automated CI/CD pipelines with zero architectural tracking or overhead.

for more information, trial, demos or price quote, DM or contact sales@[delphiparser.com](mailto:sales@delphiparser.com)

Hi everyone,

Quick question for anyone managing security compliance and SBOMs for Delphi projects:

Is there an active, dedicated Delphi CVE repository or vulnerability feed out there? one that tracks RTL, VCL, commercial, and open-source third-party components (both legacy and modern)? Or is everyone forced to rely on generic scanners pulling from NIST NVD/OSV, and then manually filtering through a sea of irrelevant false-positives to keep auditors happy?

Why we're asking: With new regulatory frameworks like EU CRA (Cyber Resilience Act) and DORA enforcement timeline approaching (late 2027), machine-readable SBOMs and automated VEX justifications are transitioning from "nice-to-have" to a mandatory legal requirement for software vendors.

To address this, we are finalizing the development of our new Delphi Parser VEX Defender - a dedicated security and compliance pipeline built specifically for the Delphi ecosystem.

How the pipeline works:

1. AST-Based SBOM: Generates a clean CycloneDX SBOM from your actual Delphi source code (uses, DFM, .dproj), eliminating non-existent dependencies and text-matching guesswork.
2. Multi-Source CVE Aggregation: Continuously pulls raw vulnerability feeds from NVD, OSV.dev, GHSA, and vendor security bulletins.
3. Centralized & Local Security DB: Aggregates and indexes a dedicated database (available both via central server and as a local offline DB for air-gapped environments) mapped directly to Delphi components, VCLs, and native C/C++ DLL wrappers.
4. Automated Noise Reduction: Filters out ~99.9% of non-relevant false positives (Java, .NET, Linux-only, or non-native threats) before they pollute your reports.
5. Deep AST & Call-Graph Reachability: When a relevant vulnerability is identified, the engine analyzes your Delphi source code (uses, DFM, .dproj, and AST call graphs) to verify whether the vulnerable code path is actually reachable and executed in your application.
6. Auditor-Ready SBOM & VEX: Automatically generates clean CycloneDX SBOMs and compliant VEX (Vulnerability Exchange) JSON files (not_affected / code_not_reachable).

Before we finalize our aggregation pipeline, we’d love to ask the community: Are there any Delphi oriented security archives, vendor bulletins, or community-driven lists we should integrate into our database?

Would love to hear how your teams are preparing for CRA/DORA compliance today!

I’m looking for feedback from Delphi developers who have successfully shipped FireMonkey desktop apps to both the Microsoft Store and the Mac App Store.

I’ve been developing Windows software for about 35 years, but this is my first serious macOS release. I’m now within inches of getting my app, Debt Blaster, across the Mac App Store goal line, and I’ve run into something I wish I had understood much earlier: TMenuBar versus TMainMenu.

For years on Windows I used TMainMenu. When I moved the application to FireMonkey, I quickly discovered that I could not theme the TMainMenu along with the rest of the FMX interface. Because I wanted the menu to follow my light and dark themes, I switched to TMenuBar. That worked well on Windows, but I am now discovering that the same choice is unconventional on macOS, where TMainMenu integrates with the native macOS menu bar.

While working through the Mac version, I finally dug into Embarcadero’s documentation:

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Using_Menus_in_a_FireMonkey_Application

The key point is that Embarcadero recommends:

Windows  -> TMenuBar
macOS    -> TMainMenu

I built a small test application to see this for myself.

With TMenuBar on macOS, the menu stays inside the FMX form. It works, but it is clearly not the normal Mac experience.

With TMainMenu, macOS does what I would expect from a native Mac app. The first visible top-level item feeds the application menu. I watched a Preferences item move under the application name. File appears in the macOS menu bar. macOS inserts its native Window menu. Help gets positioned at the far right. Quit is supplied automatically, and I confirmed that Quit <AppName> still fires my FMX OnCloseQuery, so I can protect unsaved work.

That was a very useful lesson, but unfortunately I learned it very late in the process.

My current production code already has a substantial TMenuBar with many OnClick handlers. Retrofitting this properly means adding a TMainMenu, building the Mac menu hierarchy, sharing or refactoring handlers/actions, and conditionally presenting:

Windows
  TMenuBar
  FMX themed

macOS
  TMainMenu
  native macOS menu bar

Long term, that is almost certainly what I want.

My question is about the first Mac App Store release.

I am extremely close to submission. The application is functioning on the Mac, and the current TMenuBar works. It is unconventional on macOS, but it is functional.

I am considering this release strategy:

Version 1
---------
Ship the current Mac version using TMenuBar.
Focus on functionality and getting the first Mac App Store release out.

Version 2
---------
Refactor the menu architecture.
Windows -> TMenuBar
macOS   -> TMainMenu
Move shared behavior into common handlers/actions.
Make the Mac version more Mac-native.

I am trying to avoid turning a nearly finished first release into another major development cycle just before submission.

For those of you who have actually shipped Delphi FMX applications to both the Microsoft Store and Mac App Store:

Would you ship version 1 with the working TMenuBar and make the menu architecture more Mac-native in the next release?

Or would you consider the TMainMenu conversion important enough to stop the launch and do it before the first Mac App Store submission?

I’m especially interested in experience from developers who have been through Apple review with FMX desktop applications, rather than just theoretical guidance.

I’m not looking for reasons to cut corners. I’m trying to distinguish between something that should block version 1 and something that belongs in the first post-launch Mac-native refinement pass.

Hi everyone! I’d like to share CS.Coder Project Hub, a plugin I built for Delphi 11, 12 and 13.

The idea is simple: recent projects tell you what you opened last, but they don’t necessarily reflect how you organize your work. Project Hub lets you keep your project shortcuts organized directly on the Welcome Page.

Features include:

• Categories and groups, with optional custom icons.
• Search by project name or file path.
• Drag-and-drop ordering.
• Support for .dproj, .dpr and .groupproj.
• JSON import/export to move your organization between environments.
• Support for the IDE’s light and dark themes.
• English, Portuguese, Spanish, German and French.

Everything stays on your computer—no account required. Removing a shortcut doesn’t delete your project files.

It’s free for personal and commercial use, open source under the MIT license, and provided as is.

Screenshots, installation instructions and download:
https://cscoder.com.br/projetos/hub-de-projetos-delphi/

Source code and releases:
https://github.com/cscoder69/delphi-project-hub

I’d love to hear how you organize your Delphi projects and whether this would fit your workflow. Feedback, bug reports and contributions are welcome!