Dave Nottage

Apparently you would need a BMW ZGW device, or a way of simulating one.

It appears TF is accessing resources that have been restricted in Android 12 and above. Do you plan on deploying the app to Play Store?

The target API level for Delphi 11.3 defaults to 32, which is Android 12. Since Android 10, access to shared folders has been restricted. You'll need to either manually modify AndroidManifest.template.xml to change %targetSdkVersion% to 29 (Android 10) and ensure that the android:requestLegacyExternalStorage=true attribute is present on the application opening tag, or rethink how you're accessing files, e.g. whether they need to be in a shared area at all, and if so, whether to use MediaStore or DocumentsProvider. You may want to read this.

Not sure why you would expect anyone to know without any detail whatsoever as to what your code is doing. You could use a logcat viewer to view what messages are coming from the device when the app attempts to start. See this link: https://github.com/DelphiWorlds/HowTo/tree/main/Solutions/LogViewers#android

I sincerely doubt that is the only way, however since you refuse to give a more complete example (not in a screenshot, and something that is sufficient to reproduce the issue), it's difficult to find an answer. Good luck

There's still insufficient detail in your code example (and screenshots are the worst form of example code). As per my initial reply, I said to use "a logcat viewer to look for related messages" (from the Android device), not messages in the IDE.

Your example is a bit light on details - how are all these defined? InterpreterOptionsAddDelegate InterpreterOptions GpuDelegate InterpreterCreate Model Regardless, have you used a logcat viewer to look for related messages (error, or otherwise)?

This: procedure(const APermissions: TArray<string>; const AGrantResults: TArray<TPermissionStatus>) Needs to be: procedure(const APermissions: TClassicStringDynArray; const AGrantResults: TClassicPermissionStatusDynArray) I believe the change to the types was related to C++Builder compatibility

That's likely because there's only a few supported, including the arrow keys. This is some code I used a while ago in a TV app, which I have not touched in some time: type TKeyNavigation = (None, Home, Back, Left, Right, Up, Down, OK); // KeyUp method is overridden from TForm procedure TExampleForm.KeyUp(var Key: Word; var KeyChar: System.WideChar; Shift: TShiftState); var LKeyNavigation: TKeyNavigation; LIsTV: Boolean; begin // For the following code, please refer to: // https://github.com/DelphiWorlds/Kastri/blob/c01b93369c2c33f8ab22acad611939be4789aae6/Core/DW.OSDevice.Android.pas#L216 // and: // https://github.com/DelphiWorlds/Kastri/blob/c01b93369c2c33f8ab22acad611939be4789aae6/Core/DW.OSDevice.pas#L34 LIsTV := TOSDevice.GetUIMode = TUIMode.Television; LKeyNavigation := TKeyNavigation.None; case Key of vkHardwareBack, vkEscape: LKeyNavigation := TKeyNavigation.Back; vkleft: LKeyNavigation := TKeyNavigation.Left; vkUp: LKeyNavigation := TKeyNavigation.Up; vkRight: LKeyNavigation := TKeyNavigation.Right; vkDown: LKeyNavigation := TKeyNavigation.Down; 0, vkReturn: begin if KeyChar = #0 then LKeyNavigation := TKeyNavigation.OK; end; end; if FPreventExit and ((Key = vkHardwareBack) or (LIsTV and (Key = vkEscape))) then begin Key := 0; KeyChar := #0; end; if (LKeyNavigation <> TKeyNavigation.None) and LIsTV then KeyNavigation(LKeyNavigation); end; procedure TExampleForm.KeyNavigation(const ANavigation: TKeyNavigation); begin // Use this method to determine what to do with the navigation key end; Looking at it again now, it probably needs more work.

Thanks to a message from @Stewag, I've been prompted to revisit this issue. The following code works on iOS 17. I expect it'll work on iOS 16 - not sure about earlier: unit Unit1; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.Controls.Presentation, FMX.StdCtrls; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} uses Macapi.ObjectiveC, Macapi.Helpers, iOSapi.Foundation, iOSapi.UIKit, iOSapi.Helpers; type UIViewControllerEx = interface(UIViewController) ['{3E6C5FB2-20F2-4B42-BFD8-33968A80E809}'] procedure setNeedsUpdateOfSupportedInterfaceOrientations; cdecl; end; TUIViewControllerEx = class(TOCGenericImport<UIViewControllerClass, UIViewControllerEx>) end; procedure TForm1.Button1Click(Sender: TObject); var LID: Pointer; begin Application.FormFactor.Orientations := [TScreenOrientation.Portrait, TScreenOrientation.InvertedPortrait]; if TOSVersion.Check(16) then begin LID := NSObjectToID(TiOSHelper.SharedApplication.keyWindow.rootViewController); TUIViewControllerEx.Wrap(LID).setNeedsUpdateOfSupportedInterfaceOrientations; end else TUIViewController.OCClass.attemptRotationToDeviceOrientation; end; If you run the app, then turn the device so that it is in landscape orientation, then click the button, it'll reorient the app into portrait.

Not sure how you will do that - there's no "Display Zoom" option, at least not on my iPad

Moving the procedure TConnectThread.ProcessEvent code out of the MSWINDOWS conditional define (e.g. move it to above the line {$IFDEF MSWINDOWS}) makes that unit compile. I had to also add System.Types to the implementation clause, for the DWord type.

I meant that for me, the two options for "Display Zoom" are: "Larger Text" and "Default": (i.e. I do not have a "More Area" option as per your original post)

I had a brief look and it appears it may be much more complex with a TMemo

What version of iOS are they running? iOS 16 and iOS 17 both have "Larger Text" and "Default" on my devices. Apps appear to be OK with "Larger Text" on my devices.

I meant the complete URL, which (assuming you are not using URL rewriting) would need to be something like: https://10.10.1.73/MyApp/MyServer.dll/GetDecryptedPWD Where MyApp is the app you added to the website and MyServer.dll is your ISAPI dll.

Best thing you can do for now is to use log statements.

It seems for the Barcode Reader there are no compatible binaries that can be linked in by Delphi, for iOS simulator. If you're using this feature, you'll need to compile for a real device.

You don't mention what Path you have for Action 1, and what URL you are using to access it

I've never seen a project requirement that says something like: "the interface section of SysUtils must be modified in this way" - usually it's more like: "functionality X is required", and it may turn out that the most expedient solution to the requirement is to modify the source. Your description sounds a lot like: "we have SysUtils added to the uses clause of (almost) every unit in the project, so let's change that to avoid having to create another one of our own". Amen.

Which features from Kastri are you compiling? You may just need to change the value in the Framework search paths setting in the Project Options to point to the Simulator binaries, if any are available.

You might be able to modify this code to use TMemo instead of TLabel: https://github.com/grijjy/CodeRage2019/tree/master/HtmlLabel

What exactly is the error message you are seeing?

Xcode 15 doesn't have iOS 16.x SDKs, no.. but that does not mean you cannot debug iOS 16 (or earlier) devices. With no "trickery" whatsoever. iOS 16.x devices do not have the new debugging support introduced in iOS 17, and Xcode 15 handles that. Not sure what you mean by "manually". The only "incompatibilities" are if you attempt to use features in code available in the newer SDK on a device with an older OS (when the feature is not available in that older OS). That's true, however you can import an iOS 17.x SDK from Xcode 15, build your app against it, and It will happily run on an iOS 16.x device (as long as you do not attempt to use features from a newer OS, as mentioned above), and you can use the debugger with Delphi. As I mentioned earlier, it's debugging with an iOS 17.x device that is the major issue right now.

Delphi can already use Xcode 15. The biggest issue at the moment is debugging with iOS 17 (or higher) devices, which is a problem regardless of Xcode version. Debugging on devices with iOS 16.x still works using Xcode 15. A secondary issue is this one: a problem if your app needs to link to 3rd party binaries that were built with Xcode 14 or higher.