Rollo62

Yes, that is another strategy of Apple to block unwanted, external development systems. My older MacBook Pro 2013 stucks on, I guess Catalina, which makes it completely unusable for development. The same happens now with Sonoma and older versions all the time. This is why I decided not to purchase the most capable, expensive Mac any longer, but looking for the cheapest version instead. Windows machines for the same money can do much more, more reliable and lasting much longer. Unfortunately also Microsoft is on the track of the business model of Apple now, more and more. Don't understand me wrong, cutting old tails from time to time is not a bad thing in general. But doing so in a too frequent manner is just kind of fraud. Still I'm more fond of the Windows ecosystem, the Macos ecosystem is more and more a no-go, for several lock-in syndrom reasons. Sooner or later, I think the Linux ecosystem will be the solution out of both booby traps, but unfortunately still is not ready yet for Delphi devvelopers.

Hi there, sorry for the little joke in the title, but what currently makes me headaches is the fact that after May will be broken. I used iOS as stable debugging platform for many years now, which seems to breakdown hard in a few days. The alternative Android was never that stable for debugging over the same many years, getting better now, but no replacement. The big problem now is, that Apple seems to enfore the use of their latest tools after 01.05.2024, which would make the use of XCode 14.3.1 for releases impossible. For the possible XCode changes and reasons I figured out the following possible facts for my record. Perhaps they were not all correct, maybe only a few, so please feel free to correct me, if you have more insights into the XCode ecosystem. In general, there seems to be a huge change in the new XCode debugging system. Overview of the changes seen in XCode 15: Topic Old (Xcode 14.3.1) New (Xcode 15) Comments Debugging platform partly still 32-bit using 64-bit only The new debugging platform seems to remove older 32-bit code internally completely. Debugging Framework GDB-based LLDB-based New debugging framework based on LLDB, incompatible with older GDB-based framework. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Debugging Libraries libgcc.dylib, libc++.dylib, New debugging libraries, incompatible with the older libraries used by D12.1. libstdc++.dylib libc++abi.dylib Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Symbolication Manual Automatic Xcode 15 introduces automatic symbolication, incompatible with manual symbolication used by D12.1. Debugging Protocol GDB protocol LLDB protocol New debugging protocol, incompatible with the older GDB protocol used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Breakpoint Handling Software breakpoints Hardware breakpoints Uses hardware breakpoints, incompatible with the software breakpoints used by D12.1. Debug Information STABS debug format DWARF debug format New debug information format, incompatible with the older STABS format used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I would like to know if this huge XCode change is really upcoming soon, and what can we do about it in the near future? Is there any workaround in sight? I'm afraid, that we have to wait for the next Delphi Update or Patch, which maybe changes a lot of the internals ( libraries, PAServer, workflows, ... ). Are there any news from Embarcadero, about this topic, so that we could see any light in the tunnel? Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. My considerations so far: - Use Android for Debugging, even if it not that stable. Perhaps there are ways to improve Android debugging too. - Forget Mobile debugging, rely only on Logging ( the worst case for me ). - Still use XCode 14.3.1 for debugging, while releasing under XCode 15. This is problematic, because I think XCode 14.3.1 dosen't allow to use iOS 17.4, and perhaps two versions cannot switch easily on the macOS host. Are there any tested workflows, like xcode-select --switch /Applications/Xcode14.app/Contents/Developer and xcode-select --switch /Applications/Xcode15.app/Contents/Developer ? That also means, we would possibly need two sorts of devices with iOS 16.x ( DEBUG + Log ) and iOS 17.4 ( RELEASE + Log ) for proper tests ( Permanent upgrade / downgrade is not an option ). - Embarcadero already had worked out a stable Update 2, to simply make iOS 17.4 debuggable and testable. ( The best case for me ). - Any smart hack, to make XCode 14.3.1 producing releases still? Perhaps, setting a build-ID could do the job, but I'm completely unsure about that. When Apple finds such hacks, this may also be considered as infringement and lead in blocking the app in the store, which could be even harder. - Other ideas / news / thoughs, are there any ? Edit: See above table, it seems that Delphi >= Alexandria can already make use of LLDB debugging system: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

@Dave Nottage Thanks for giving hope and pointing to the right direction, as always As expected. simply starting and debugging an iOS 16.7.5 device with SDK 17.4 fails, with the following message: Starting the Debug Build without debugger ( Ctrl+Shift+F9 ) works well, start and seems OK so far. After a few more steps, I could really debug again on XCode 15.3 + iOS Device 16.7.5 + iOS SDK 17.4. Edit: Worth to mention: Running on MacBook Pro Intel: MacosOS Sonoma 14.4.1; Parallels Desktop 19.3.0 Here is the whole process is documented: I hope that can help another poor guy, who is getting crazy from the mysterious Apple moves.

Immutable objects have their own, non-changeable state and are therefor thread-safe by design https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

Dear Dave, thanks for giving me a little relief on the upcoming forced upgrade. With "manually" hooking the older SDK, I mean the formerly needed manual copy and past from old XCode SDK into new XCode SDK's PackageContent. Is this not necessary too, which means that XCode 15 still offers 16.7.7 SDK without much hazzle? Please note: My main goal was not loosing the debugging ability. This would require from my understanding an XCode iOS 16.7.7 SDK and an iOS 16.x device. When using iOS 17.x SDK, I'm in danger to loose debugging option, right? Nevertheless, I will try to install XCode 15, but want to do that as safely as possible, to avoid destroying my current, well-working workstation setup. Here I've made a little "actipn plan", how to keep old and new XCode safely side-by-side. This is hopefully complete and let me switch safely between old and new. without and negative impact. Here I've tried to separate XCode 1431 and 1520 as much as possible. Maybe thats helpful for other too, I will check that soon and get back if something turns out terrible wrong:

Thanks for clarification, I assumed that XCode 15 won't support or can handle older iOS 16.x SDKs any longer. If XCode 15 is bundled with and hardly enforces SDK 17.4, or not allow to load or use SDK 16.x and longer, then this won't help either. Can you confirm that XCode 15 can still be used for debugging same as XCode 14.3.1, under iOS 16.x, without too much trickery ? The older SDK will have to be hooked into XCode manually, with all possible incompatibilities. If would expect something like this: Ok, I found this, which states that Delphi already supports the newer LLDB debugging system, perhaps since Alexandria, and that should be a good thing. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I will update my table above accordingly. Are there any official notes about whats changed internally and whats currently still possible? I must confess, that I had not followed the WWDC videos, because lack of time, would be great to find some official statements about these changes and roadmaps.

Thanks, this is what I found too, see my original post. Nevertheless there seems nothing from the official Apple sources or forums.

Hi there, I'm still evaluating the D12.1 version currently, it all looks pretty much OK so far. What I have notices is, that the info.plist now containse more entreies: <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>16.4</string> <key>DTPlatformBuild</key> <string>20E238</string> <key>DTXcodeBuild</key> <string>14E300c</string> <key>DTSDKBuild</key> <string>20E238</string> Al this is understandable, to improve the development tools stability. Only the DTPlatformName wonders me, since I have checked "iPhone & iPdad" for the UIDeviceFamily: Which appears like this: <key>UIDeviceFamily</key> <array> <integer>1</integer> <integer>2</integer> </array> The general conclusion is like this: UIDeviceFamily: Defines the device classes on which the app can be executed. The possible values are: 1: The app is intended for iPhone (and iPod touch). 2: The app is intended for iPad. If both values are specified, the app supports both iPhone and iPad. DTPlatformName and other DT keys: These keys are specifically intended to provide information about the development environment and target platform, including the version of Xcode and iOS SDK used to build the app. They are important for the build and review process in the App Store, but they are not directly affected by the UIDeviceFamily setting. Perhaps this means, that the app should be broadly compatible within the iOS ecosystem, which is relevant during development and later distribution via the App Store. This also seems to fix an known error: https://docwiki.embarcadero.com/Support/en/“ERROR_ITMS-90507:_Missing_Info.plist_value._A_value_for_the_key_'DTPlatformName'_is_required”_when_submitting_an_app_to_the_iOS_App_Store Here some info from another source: https://github.com/godotengine/godot/issues/74154 https://forums.developer.apple.com/forums/thread/111697 What the heck is this DTPlatformName good for, is there any offical documentation about it? Maybe there are there other options too ...

You could consider a more asynchronous design, for example with TTask, that could avoid the pitfalls of Applicaton.ProcessMessages completely. The use of immutable objects could make your design even more robust. procedure TMyProcess.RunMyProcess; begin TTask.Run( procedure var LImmutableStatus : TImmutableObject; LImmutable : IImmutableObject; begin try LImmutableStatus := TImmutableObject.Create; while ProcessIsRunning do begin Step1; Step2; LImmutable := LImmutableStatus.Clone; TThread.Synchronize(nil, // or better TThread.Queue( if you want to avoid blocking procedure begin { Update User Interface } UpdateUIWhenNeeded( LImmutable ); LImmutable := nil; end ); Step3; end; finally TThread.Queue(nil, UpdateUIWhenNeeded ); LImmutable := nil; LImmutableStatus.Free; end; end ); end; Just as a rough idea, without checking your specific needs.

Have you tries with the SDK/NDK/JDK that are shipped with the Delphi originally? https://delphiworlds.com/2024/04/delphi-12-1-and-codex-2-2-released/ I think this might be critical, because of the deep changes in this Android tools and internals. I would recommend to stay with the original D12.1 setup and files in the first place, if there is no specific need to really upgade the SDK.

Good thing that 👍 But can anyone open the RSS-425 ? The rest is working well.

https://blogs.embarcadero.com/6-books-about-delphi-you-should-read/ https://en.delphipraxis.net/topic/10623-good-delphi-learning-sites-for-new-team-member/?tab=comments#comment-84363

Hi there, I want to share some insights, to change the "Release notes" of an already published version, without uploading a new *.AAB version. From time to time you had just uploaded and publishes a new release, but you find some better or more description under the "Whats new" section of the Play Store. You can change this without uploading a new release, which is not so obvious, because this feature is a little hidden and it took some time to reveal its secrets. Here is the current workflow step-by-step: Enter App page in the PlayStore Enter Production tab on the left navigation bar Select Releases tab Click Manage Release on the right-hand side Scroll down to botton "Release Notes" Click "Edit release details" on the right-hand side Edit and Save Thats all, the changes will appear immediately in the PlayStore, without another review. Nice.

Yes, underlying hardware issues which could causes by various reasons, from permissions to misbehaving sensors and many more. Since then, I enclose all these features inside a double-protection, to be hoepfully able to catch more of such execeptions.

I'm not too deep in these topics, but as far as I know, the runFullTrust capability seems to be required: https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations#restricted-capabilities, at least for certain permissions or operations:

Perhaps this did the trick: https://en.delphipraxis.net/topic/11151-delphi-and-use-only-memory-safe-languages/?page=5&tab=comments#comment-90366

Yes, they already removed the plugins from the Pro plan. With the tip above you could at least still reach them ( not sure for how long). If you look for prompt design tipps, I haven't looked recently. I think its always good to check current state, since this might change daily. A good start would be at OpenAI's instruction perhaps: https://platform.openai.com/docs/guides/prompt-engineering Here is some interesting training site, how to improve your prompt skills learning by doing, but I doubt this is nothing more than a nice toy for fun: https://experiments.withgoogle.com/say-what-you-see

Hi there, as you have might have noticed, the ChatGPT PluginStore is already removed and will be completely shut off soon. Winding down the Plugins-Beta Nevertheless, there is still an option to run ChatGPT with Plugins up to now: https://chat.openai.com/?model=gpt-4-plugins Hope that helps anyone.

My recommendation would be, to avoid 3rd Libraries as much as possible. Since FMX on Mobile is very volatile and Android/iOS change significantly every 6 months, it is very important not to rely on additional, possibly unstable, external components. My recommendation would be, to make as much as possible on your own. I can recommend DelphiWorlds-Kastri as a common life-saver, TMS FNC and other TMS components - since they are quite active, but I would still reduce any external reference as much as possible. Moreover, I would not directly try to port a desktop app to mobile. Better to start clean with a mobile-first app and then put your "desktop" functionality back step-by-step.

Do I get this right, no browsing function yet ? Or will this be activated later? So far, this morning, I could find nothing.

Yes, you can safely ignore them ( until Google decides to enforce this probably in the future ). I considered that too, but I'm afraid these warning will be hard to remove, because they require certain Android tools, like ProGuard. Not sure if this will be ever included in the Delphi process. One idea, at least for the first warning, was to add a neutral or empty "manifest.txt" file. This might work technically, but on the other hand, the Google Review might see this as an attempt to circumvent or infringe their PlayStore policies, which might put you in bigger troubles. My hope is, that Embarcadero put this onto their roadmap.

Nice list, thanks 👍 You missed these few, probably: https://rosettacode.org/wiki/Parse_command-line_arguments#Delphi https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.SysUtils.FindCmdLineSwitch https://github.com/exilon/QuickLib/blob/d085aa28e5fd65bae766446f5355ec4dc80fae9e/Quick.Commons.pas#L1292 https://wiert.me/2015/05/13/on-the-delphi-tcommandparser-class-for-parsing-command-lines-and-arguments-via-suggestions-for-how-to-define-command-line-parameters-stack-overflow/ https://github.com/jackdp/JPLib/blob/master/Base/JPL.CmdLineParser.pas https://github.com/tokibito/delphi-argparse

I did, but I would wish a little more screenshots, to understands what is this all about.

Could this have something to do with it? https://blog.marcocantu.com/blog/2023-october-nativeint-weak-alias.html Like Uwe said, a little more code would be nice.

More on memory safety, from Marco Cantu. Regarding marketing, what comes into my mind is: Can the memory safety of RadStudio C++ safely assumed to be more improved than standard C++, because it's close relation to its sibling Delphi within the same package? My marketing mind screams: Of course RadStudio C++ is advanced, because the memory safety of RadStudio Delphi rubs off on RadSudio C++. P.S.: "rub-off" is a professional software developer term, that decision-makers in government and elsewhere can easily adapt and understand.