Hans♫

Good to hear. It's of course a tradeoff. Using a VM requires extra time and so do running multiple Delphi version directly in your main Windows installation. My conclusion so far is that the latter works better for me, despite often having problems when a new Delphi version is released.

I solved it. There was still a node for "RAD Studio 12" in the Windows 10 uninstall registry. So I simply deleted that node from here: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ PS. Using VM for multiplatform development is a PITA.

You are right, I didn't make any changes to the settings tree, as I expected it to be correct by default when having chosen "... to newer product version" on the first page. Lesson learned! Unfortunately I am still in a dead-lock that I cannot install Delphi 12 because it thinks its already installed. Have contacted support and waits for an answer, but I expect that it is just a single obfuscated registry value that needs to be removed to continue. Just don't know which.

I used the option "Migrate settings to a newer product version". Do you suggest to use the other option "Export settings to a migration file"?

Short version: I am now trying to manually uninstall Delphi 12, but I keep getting this message when I want to install Delphi 12 again: The installer will no let me proceed as the uninstaller fails (it does not exist). I have followed the guide written here: But something must be missing. Any suggestions what I can do to make the installer run again? Long version: 1) Installed Delphi 12 using the web installer (RADStudio_12_0_inline_esd_116924.exe). Installed platforms Windows, MacOS, iOS and Android. 2) Used the migration tool when suggested during installation, and chose the upgrade feature to migrate from existing Delphi 11.3 3) Running Delphi 12 for the first time, but with a lot of error messages. It tried to load all the Delphi 11.3 packages, which of course fails. 4) Removed all invalid packages manually so it now runs without errors. 5) Discovers that iOS and Android platforms are not shown, despite being installed. This is the general IDE options (without having loading a project): 6) Used the "Manage features" to uninstall iOS and install it again, but same problem. The manage features window shows that all is installed: 7) Uninstalling Delphi 12 from Windows 10 > Settings > Apps, but the uninstaller failed in a way. It showed a message "Uninstalling GetIt ... (this may take a while)", then opened a command prompt, but nothing happened in the command prompt and after 30 minutes I closed the command prompt and uninstall continued, and, as far as I remember, completed without any errors. 😎 Installing Delphi 12 again, but shortly after having selected all platforms and clicked continue, it failed. Unfortunately I did not get a screen shot of the error. 9) Now I began to manually remove all Delphi 12 files, so I could make a clean installation again, but here I am stuck as described in the beginning of this post. Something remains that is linked to Delphi 12, but not clearly identified as belonging to Delphi 12. I already have Delphi 10.4 and Delphi 11.3 on the computer, so I don't want to remove ALL Embarcadero related data. I suppose it all started because I used the Migration tool, which I have always done with success, but this time it messed everything up.

No it is English text that is hardcoded in our app, just like in the example. But .ToUpper uses the OS locale (i.e. Turkish), which means that the uppercase edition of "i" is not "I".

We have received reports from our Turkish users that our app is failing. Our debugging comes down to this simplified code: lStr1 := 'This'; lStr2 := 'THIS'; if lStr1.ToUpper = lStr2.ToUpper then begin //This code is NOT executed if local is Turkish! end; This happens in both Delphi 11.3 and Delphi 12, and it happens on all platforms: Windows, MacOS, Android and iOS. The reason is that the uppercase edition of the letter "i" becomes "İ", which is not the same as "I", while the uppercase edition of "I" remains unchanged. The problem is solved by using "SameText", but I still find that the above behavior is strange.

Thank you. It looks like the exact same problem, but interesting that it has been reported for Ventura. With our code the error does not happen in Ventura, only on Sonoma.

This must be a bug in Delphi, but it seems to be out of my hands, so for now we just replace our JPG files with PNG files. However, in case someone would experience similar problems or want to look into it, here is what I have found. We load the exact same jpg file using the exact same code, but the result: Windows: OK iOS: OK Android: OK MacOS not Sonoma: OK MacOS Sonoma with ARM processor: OK MacOS Sonoma with Intel processor: Exception Stacktrace: System.Error(System.TRuntimeError)(reInvalidOp) System.FRaiseExcept(unsigned int, bool)(1,true) System._Round(long double)(NaN) Fmx.Multiresbitmap.TBitmapOfItem.DoChange()($000060000198c420) Fmx.Graphics.TBitmap.BitmapChanged()($000060000198c420) Fmx.Graphics.TBitmap.SetSize(int, int)($000060000198c420,3000,1496) Fmx.Graphics.TBitmap.AssignFromSurface(Fmx.Surfaces.TBitmapSurface*)($000060000198c420,$0000600003388c00) Fmx.Graphics.TBitmap.Assign(System.Classes.TPersistent*)($000060000198c420,$0000600003388c00) Fmx.Graphics.TBitmap.LoadFromStream(System.Classes.TStream*)($000060000198c420,$0000600002846a80) Uoscommon.LoadBitmapResource(Fmx.Graphics.TBitmap*, System.UnicodeString)($000060000198c420,'HomeBackGround2048') Fomain.tMainForm.FormCreate(System.TObject*)($00007fd5090cfa00) Fmx.Forms.TCommonCustomForm.AfterConstruction()($00007fd5090cfa00) System._AfterConstruction(System.TObject*)(0x7fd5090cfa00) Fomain.tMainForm.tMainForm(System.Classes.TComponent*)($00007fd5090cfa00,true,$00007fd509907af0) Fmx.Forms.TApplication.CreateForm(System.Classes.TComponentClass, void*)($00007fd509907af0,0x1021a0bd0,0x1021a46d0) Fmx.Forms.TApplication.RealCreateForms()($00007fd509907af0) Fmx.Platform.Mac.TPlatformCocoa.Run()($00007fd508715880) Fmx.Forms.TApplication.Run()($00007fd509907af0) main(1,0x7ff7bfeff8e0,0x7ff7bfeff8f0,0x7ff7bfeff9a0) :00007FF80ED623A6 ?? It happens when calling "Round" in this procedure: procedure TBitmapOfItem.DoChange; begin inherited; if (FBitmapItem <> nil) and (not FBitmapItem.FDormantChanging) then begin FIsChanged := True; FBitmapItem.FWidth := Round(Width); //<- exception here. Width is an integer property with value 3000 FBitmapItem.FHeight := Round(Height); if (FBitmapItem.Component <> nil) and ([csLoading, csDestroying] * FBitmapItem.Component.ComponentState = []) and (FBitmapItem.Collection is TCustomMultiResBitmap) and (TCustomMultiResBitmap(FBitmapItem.Collection).UpdateCount = 0) then FBitmapItem.Changed(False); end; end; The Round function being called that raises the exception: function _Round(Val: Extended): Int64; type TWords = Array[0..4] of Word; PWords = ^TWords; begin if (PWords(@Val)^[4] and $7FFF) >= $403F then FRaiseExcept(feeINVALID); Result := llrintl(Val); end; The image being loaded is added to the project as a ressource with the ID "HomeBackGround2048", which refers to a JPG image with dimensions 3000x1496. We load it using this function: procedure LoadBitmapResource(const aBitmap: TBitmap; const aResourceName: string); var lStream: TResourceStream; begin lStream := TResourceStream.Create(HInstance, aResourceName, RT_RCDATA); try aBitmap.LoadFromStream(lStream); finally lStream.Free; end; end;

It's strange that we have not had any reports from iOS 17 users, and our own tests on iOS 17 also runs fine. Our analytics tells us that 400 unique users have started our software on iOS 17 until yesterday. We use in-app purchases too and those two .release lines are still active in our copy of FMX.inAppPurchase.iOS.pas. We have other modifications of the file though, so maybe it makes a difference just by compiling it your self?

If Marco Cantu reads this, I would highly recommend Embarcadero to prioritize a rock solid compatibility to new SDK/API version on alle platforms. New features are nice, bug fixes are very nice, but the uncertainty about support for platform changes can ruin it all. I know it is easier said than done because the marketing people will scream for new features to promote. That is the tradeoff in all software companies. But the whole revenue in our company is based on being available on all platforms, and it requires "nerves of steel" to be so close to the edge of the cliff so often.

Thank you, I did not see this option. I applied and we now have an extended deadline until November 1st.

I see that someone also created an issue in Quality Portal about this: https://quality.embarcadero.com/browse/RSP-42164

Ok, last time we tried to go ahead of the default API level in Delphi, we had a lot of trouble. Looks like this is still the case... I think for now we will try to get our next update out before the deadline.

We already use a new installation of Delphi 11.3 Patch 1, but it targets API level 32. It installs this: file:///C:/Users/Public/Documents/Embarcadero/Studio/22.0/CatalogRepository/AndroidSDK-2525-22.0.47991.2819/platforms/android-32 What did you do to target API level 33? PS. It is installed on a VM that had Delphi 11.2, but upon installation of Delphi 11.3 it uninstalled 11.2 first.