Rollo62

Interesting, 8GB would feel a little too small for me. Nevertheless, I use a MacMini M2 for such tests running XCode on ARM M2, but I have never tried to install a VM with Delphi on it. I only remote-access the PAServer there, to build ARM M2 binaries, which works very well. Perhaps I'm forced to try the Delphi on MacMini in April, sooner as I loved to. Nevertheless, it would make more sense to run Delphi from a Windows Workstation. But the MacBook is not completely dead directly, it might still be used as Delphi workstation, only using the external MacMini for builds and iOS.

Yes, but I currently run Delphi 13 under Parallels VM, thats why I have 32GB machine to run it smooth. This is what I meant, by changing the whole infrastructure. Do you run Delphi under Parallels VM on the MacMini M1 8GB too and if so, isn't it too slow? My plan would be at least to have 16 GB, but Apples RAM pricing strategy is really ridiculous.

Yes, I wanted to update to the latest Sequoia version, which should be Macos 15.7.1. https://support.apple.com/en-us/120283 So that means it will debug this Macos too, not only iOS 17+, which was the last status I have noted in my files? My understanding ist that the debug issue only affected iOS, not Macos (yet), I hope I'm right. Great, that sounds very promising that its already running. Thats my plan, to move slowly step-by-step, to avoid additional, unwanted issues. Currently I'm a little under fire, because of missing updates, so I don't want to mix up anything. To upgrade until next year April will be fine. First I have to get back some stable ground again, in the Delphi / Apple / Android swamp, to move on safely. Actually I thought that it would last until September 2026 with its Tahoe enforcement, but if you say its only April 2026, then this means I have to re-structure my whole setup hardware here too, with a new Mac machine. The (old) Intel MacBook Pro was a nice piece of hardware, but not worth it, if it lasts only a handful of years as development machine, so my plan for the new year will be to move entirely from MacBook Pro Intel to MacMini M2+x ( and maybe a Windows Workstation instead, if the MacMini doesn't to Parallels VM well ). Apple is always the source for the biggest headaches, just before Android.

Thanks, but that part was clear to me. Whats unclear is, how about debugging under Intel MacBook, MacOS Sequoia 15.6 apps itself? What is the latest, most stable upgrade path for Delphi 13 ( Intel MacBook, MacOS Sequoia 15.6 , XCode 16.4, iOS 18+, ... )? I cannot move to MacOS Tahoe, because that will break my whole Workstation support as well, not only the iPhone part, and I would have to switch to another Mac. But I think MacOS Tahoe is far out of reach for Delphi 13 anyway, I hope they can fix this within one year. My problem now is, that I cannot upload to store anly longer, with my XCode 15.4.

My old iPhone X with max. version iOS 16.7.12 seems to be banned from Apple development now, so it seems I have to purchase a newer development iPhone iOS 17+. When I borrowed an iPhone 14 Pro with iOS 17.6.1and using XCode 15.4 with SDK iPhoneOS 17.5 I can build and run fine with Delphi 13 Patch 1. Only when trying to debug, Delphi 13 P1 shows this ( German message, although IDE is fully english setting ) meaning: "Debugging of the app on devices with iOS 17 or higher is currently not supported." What is new now is, that I cannot build and upload an Release any longer, getting this message from Transporter: So finally I need to install Delphi 13 P1 with the desired XCode version ( XCode 16.4 seems the latest, known supported, from above statements and this additional note from Dave ) https://en.delphipraxis.net/topic/13630-linker-errors-all-of-a-suddenios/?do=findComment&comment=104840 While the latest current version of the 16.x line seems to be XCode 16.4, the next version jumps to XCode 26 https://developer.apple.com/download/applications/ From this thread so far, I would assume that XCode 16.4 line should still work as expected, while the next XCode 26 perhaps breaks even more. By the way, it seems Apples XCode Release notes claims support from iOS 15 still well https://developer.apple.com/documentation/xcode-release-notes/xcode-16_4-release-notes What puzzles me is the strange table from Embarcadero, for the latest Delphi 13 Florence Version which lists only XCode 15 ?? https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#Development_Tools_Support Is that just a typo, or what does it mean? If that is true, that would mean no upload to AppStore would be possible, right? Because XCode 15.45 would not include support for SDK 18: https://developer.apple.com/documentation/xcode-release-notes/xcode-15_4-release-notes I've tried to stay as long as possible under XCode 15.4, because it was still able to debug iOS, but XCode 15 is quite too old and even XCode 15.4 is not supported any longer. So the best compatible pathway is a little uncleat still. The debug issue with iOS 17+ under XCode 16.x is clear, whats not so clear is, if XCode 16.4 can still debug Macos Apps then with Delphi 13 P1. This would be my last resort emergency fallback, but I assume the next step to XCode 16.x will remove all debug options, is that correct? Would be good to know what breaks and whats not, before upgrading to XCode 16.4, using Delphi 13 P1 and purchasing a new iPhone.

Seems back to normal for me. 👍

That is correct, I also wondered why this was not simply copied to the main Embarcadero/37.0/PAServer/ folder, as it should be the normal way patches shall work, IMHO. I also had to search this for little while.

Ok great, it forces you to change the name in all places, at least nicely supported by compiler and CodeCompletion, thats fair enough. 👍

I cannot find any background information to NameOf(), how it internally really works. It seems to be implemented intrinsic in System.NameOf, but how does it magically retrieves a name at runtime? If this NameOf() call intrinsically also includes the RTTI-System by calling System.TypeInfo or the like, as an unwanted side-effect, that would not be a good thing, IMHO. Perhaps its some other kind of compiler magic, that is going on here. 🤔 Who knows what it really does, under the hood? Edit: Ok, I just checked what it can do and whats not. It really seems to replace only like: typing the text "nameof( Sender );" instead of "Sender"; typing the text "nameof( Self );" instead of "Self"; in the code. My gut feeling was right, yes its useless and even has more text to type. Or do I oversee some hidden useful magic or some really fancy use-cases here? Maybe the use in Attributes would make some sense https://en.delphipraxis.net/topic/1775-i-wish-i-had-rtti-for-constants-andor-a-compiler-magic-nameof/?do=findComment&comment=108278

Still no iOS 17 debugging in Delphi 13, including September Patch. What can be the problem, since other IDE's seems to have solved this issue already one year ago? When I peek a little deeper into this: The root cause seems to be the change from usbmuxd to devicectl, as far as I can see, enforcing the new CoreDevice.framework. // Communications-Stack until iOS 16: ┌─────────────────┐ │ IDE/Tool │ ├─────────────────┤ │ libimobiledevice│ (Open Source) ├─────────────────┤ │ usbmuxd │ (USB Multiplexer Daemon) ├─────────────────┤ │ lockdownd │ (iOS Service) ├─────────────────┤ │ iOS Device │ └─────────────────┘ // Communications-Stack since iOS 17: ┌─────────────────┐ │ IDE/Tool │ ├─────────────────┤ │ devicectl │ (CLI Tool) ├─────────────────┤ │ CoreDevice.fw │ (Closed Source) ├─────────────────┤ │RemoteXPC Service│ (New Protocol) ├─────────────────┤ │ iOS Device │ └─────────────────┘ It seems to change a few permission requirements and the protocol, but it mainly seems to be a doable change on the communication level, IMHO. Maybe I'm wrong and there were deeper changes and showstoppers too. I cannot find much about the CoreDevice.framework, it seems to be still private and not fully public (perhaps still under development). https://marcoeidinger.github.io/appleframeworks/ Is this perhaps the reason that Embarcadero has no sources available yet, to implement a solution??!! I would think that Embarcadero should have all files to provide a solution, but maybe need to wait until Apple officially makes it public. Does it make sense to look after other IDE's, how they solved the issue and learn from them about fixes and workarounds under Delphi 13 too? So far I cannot see a clear, official solution description yet, but others seems to have it.

What means "fixed", where is this noted? There are use-cases in views where I want edge-to-edge and where I don't. Is there a kind of switch in Delphi to handle this, perhaps even on-the-fly? Personally I think the right way would be to do this in the manifest file, but this is for the whole application only. Perhaps it would make sense to have options to switch the Form between normal, normal-edge-to-edge, fullscreen, fullscreen-edge-to-edge, without hacking this on my own. Now a solutions could be to insert layouts and elements on the form, in the way you want, showing or don't showing depending on the version. I'm still installing and setup a fresh Delphi 13, if you have infos I can try to test this.

Perhaps this will do it: https://learndelphi.tv/ https://www.amazon.de/-/en/Code-Faster-Delphi-Alister-Christie/dp/B08KH3R42T

Ok, it has kindof strange infos too, like bugfix would be possible somehow. https://docwiki.embarcadero.com/RADStudio/Florence/en/Release_Notes#Launching_iOS_fails_with_PAServer_22 it doesn't say here either very clearly https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#Supported_Platforms_and_Operating_Systems Perhaps its not clearly noted, that there were any issues. For example at Delphi 12 it clearly stated that its not able to debug on iOS 17 devices, https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#cite_note-iOS17-2 Strange, why did they removed this note in Delphi 13? Maybe they intend to fix this in an early patch.

Good question, I've tried this "How can I debug iOS with Florence?" As far as I know, debugging iOS ist still broken, which I can find also in the release notes for example If this compainion was trained on the current data, then its a little off here. So I wonderwhat they used for training really, I hope also some insights from Jira or the like.

There are a stunning 5.4% not using AI at all, hooray, brave men and ladies