Rollo62 502 Posted April 23 (edited) 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 Edited April 24 by Rollo62 Share this post Link to post
Dave Nottage 493 Posted April 23 12 hours ago, Rollo62 said: Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. 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. 2 Share this post Link to post
Rollo62 502 Posted April 24 7 hours ago, Dave Nottage said: 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. 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: Quote Integration of an older SDK in Xcode 15: - Obtaining the older SDK: Older iOS SDKs are not directly available through official channels. They must be extracted from an older Xcode version. - Extracting the SDK: Navigate to the Xcode app in the Finder (right-click and select “Show package contents”). Find the SDK folder, typically in the path (Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/). Copy the desired SDK folder (e.g. iPhoneOS16.74.sdk). - Add the SDK to Xcode 15: Go to the corresponding directory (Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/). Paste the copied SDK folder here. Boot XCode. - Macos Delphi Scratch-Dir, remove the scratch directory and its entry - Delphi SdkManager, check für SDK and "Update local cache" 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. Share this post Link to post
Dave Nottage 493 Posted April 24 Just now, Rollo62 said: I assumed that XCode 15 won't support or can handle older iOS 16.x SDKs any longer. Xcode 15 doesn't have iOS 16.x SDKs, no.. but that does not mean you cannot debug iOS 16 (or earlier) devices. 1 minute ago, Rollo62 said: 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 ? With no "trickery" whatsoever. iOS 16.x devices do not have the new debugging support introduced in iOS 17, and Xcode 15 handles that. 7 minutes ago, Rollo62 said: The older SDK will have to be hooked into XCode manually, with all possible incompatibilities. 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). 9 minutes ago, Rollo62 said: Older iOS SDKs are not directly available through official channels. They must be extracted from an older Xcode version. 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. Share this post Link to post
Rollo62 502 Posted April 24 (edited) 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: Quote 1. Before Installation: - Macos: Delete Delphi 'Scratch-Dir 2. XCode: - Ensure separate versions - XCode 14.3.1 - Duplicate DerivedData ( BACKUP ) Macos: cp -R ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/DerivedData_1431 - Duplicate Archives ( BACKUP ) Macos: cp -R ~/Library/Developer/Xcode/Archives ~/Library/Developer/Xcode/Archives_1431 Macos: Check success by: ls ~/Library/Developer/Xcode/ - Duplicate XCode.plist ( BACKUP ) Macos: cp ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Preferences/com.apple.dt.Xcode_1431.plist Macos: Check success by: ls ~/Library/Preferences/*Xcode*.plist - XCode: Point to new, DerivedData_1431 folder # XCode/Settings/Locations/Derived Data/ choose from "Default" to "Custom" # XCode Enter new folder location, addinf _1431, to ....../Developer/Xcode/DerivedData_1431 # Check success: Press the small icon right after the path, to open in Finder. - XCode: Point to new, Archives_1431 folder # XCode/Settings/Locations/Archives/ choose from "Default" to "Custom" # XCode Enter new folder location, addinf _1431, to ....../Developer/Xcode/Archives_1431 # Check success: Press the small icon right after the path, to open in Finder. - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning Check XCode version: xcode-select -p Set if needed: : sudo xcode-select -s /Applications/Xcode_1431.app - Rename XCode.app to XCode_1431 # After renaming under XCode/Settings/Locations/CommanDLine Tools, the selection of the correct command line tools needs to be done again, requiring another password entry, but then is pointing to the changes XCode_1431.app. 3. XCode: - Ensure separate versions - XCode 15.x - Setup as usual Check XCode version: xcode-select -p Set if needed: : sudo xcode-select -s /Applications/Xcode.app - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning 4. XCode: - Ensure separate versions - XCode 15.2 - Duplicate DerivedData ( BACKUP ) Macos: cp -R ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/DerivedData_1520 - Duplicate Archives ( BACKUP ) Macos: cp -R ~/Library/Developer/Xcode/Archives ~/Library/Developer/Xcode/Archives_1520 Macos: Check success by: ls ~/Library/Developer/Xcode/ - Duplicate XCode.plist ( BACKUP ) Macos: cp ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Preferences/com.apple.dt.Xcode_1520.plist Macos: Check success by: ls ~/Library/Preferences/*Xcode*.plist - XCode: Point to new, DerivedData_1520 folder # XCode/Settings/Locations/Derived Data/ choose from "Default" to "Custom" # XCode Enter new folder location, addinf _1520, to ....../Developer/Xcode/DerivedData_1520 # Check success: Press the small icon right after the path, to open in Finder. - XCode: Point to new, Archives_1520 folder # XCode/Settings/Locations/Archives/ choose from "Default" to "Custom" # XCode Enter new folder location, addinf _1520, to ....../Developer/Xcode/Archives_1520 # Check success: Press the small icon right after the path, to open in Finder. - Check if all changes still behave properly, restart XCode, PAServer, Delphi, Open project, try build & run, check provisioning Check XCode version: xcode-select -p Set if needed: : sudo xcode-select -s /Applications/Xcode_1520.app - Rename XCode.app to XCode_1520 5. Switching between XCode_!431 and XCode_1520 - Set : sudo xcode-select -s /Applications/Xcode_1431.app sudo xcode-select -s /Applications/Xcode_1520.app Check : xcode-select -p Restore: cp ~/Library/Preferences/com.apple.dt.Xcode_1431.plist ~/Library/Preferences/com.apple.dt.Xcode.plist cp ~/Library/Preferences/com.apple.dt.Xcode_1520.plist ~/Library/Preferences/com.apple.dt.Xcode.plist Edited April 24 by Rollo62 Share this post Link to post
Rollo62 502 Posted April 24 (edited) @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: Quote Update XCode 15.3: - XCode 15.3 with SDK iOS 17.4: Compilation OK - App is deployed to device iOS 16.7.5: Can be started there, seems to be running OK. - Problem trying debugging within IDE: Debugging message in PaServer: ">iOS-Ausgabe: dyld[4221]: Library not loaded: @loader_path/python3.10/Python Referenced from: <402E8408-6EBB-39CB-BB4F-9E0365D28396> /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/liblldb.15.0.7.dylib Reason: tried: '/Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python' (no such file), '/usr/local/lib/Python' (no such file), '/usr/lib/Python' (no such file, not in dyld cache) " - Python-Version 3.10 seems not available for the symbolic link of PaServer Situation: "$ python3 --version Python 3.9.6 $ which python3 /usr/bin/python3 $ python3 -c "import sys; print(sys.exec_prefix)" /Applications/Xcode_1530.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9 $ python3 -c "import os; import sys; print(os.path.join(sys.exec_prefix, 'lib', 'libpython3.10.dylib'))" /Applications/Xcode_1530.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/libpython3.10.dylib " - Install Python 3.10: brew install python@3.10 - ensure python3.10 links correctly: python3.10 --version which python3.10 Result: Python is installed $ python3 --version Python 3.9.6 $ which python3.10 /usr/local/bin/python3.10 - Identify correct path to libpython3.10.dylib: python3.10 -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))" - Can vary, use this too: find /usr/local -name 'libpython3.10.dylib' Results: "$ python3.10 -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))" /usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib $ find /usr/local -name 'libpython3.10.dylib' /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/python3.10/config-3.10-darwin/libpython3.10.dylib " - Create the correct symbolic link for PaServer: There are two paths, use the more general: sudo mkdir -p /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10 sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python Results: "$ sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python ln: /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python: File exists " - It seems already existing link: Check where it points to: ls -l /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python - If the link doesn'T point to the correct libpython3.10.dylib, delete and recreate: sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python Results: "$ ls -l /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python lrwxr-xr-x 1 root staff 87 Mar 18 18:35 /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python -> /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Python3 " - Remove the existing symlink: sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python - Create the new: symlink: sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python - Restart PAServer: Results: "$ sudo rm /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python Password: $ sudo ln -s /usr/local/Cellar/python@3.10/3.10.14/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib /Applications/PAServer-23.0.app/Contents/MacOS/lldb/lib/python3.10/Python" No failures. Restart PaServer with error: "Last login: Wed Apr 24 18:14:37 on ttys000 /Applications/PAServer-23.0.app/Contents/MacOS/paserver -port=64211 The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050. $ /Applications/PAServer-23.0.app/Contents/MacOS/paserver -port=64211 Platform Assistant Server Version 14.1.13.8 Copyright (c) 2009-2024 Embarcadero Technologies, Inc. EIdCouldNotBindSocket: Socket konnte nicht gebunden werden." " - Check occupied ports „EIdCouldNotBindSocket: Socket konnte nicht gebunden werden“ lead to Port (64211) is occupied. Check the port: sudo lsof -i :64211 Result: Several processes still running "$ sudo lsof -i :64211 Password: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME iosinstal 3921 rowa 5u IPv4 0x6bc8063830379fa9 0t0 TCP *:64211 (LISTEN) iosinstal 3921 rowa 6u IPv6 0x6bc8062500cb5ae9 0t0 TCP *:64211 (LISTEN) iosinstal 3921 rowa 7u IPv4 0x6bc8063830377169 0t0 TCP rowa-macbook-pro-5.fritz.box:64211->plsmb02-alex-p02.fritz.box:49975 (CLOSED) " - Kill the running processes b< PID: sudo kill -9 3921 - Restart PaServer Result: - PaServer start without failure: OK - Delphi App, no Debugging, starts via IDE: OK - Delphi App, with Debugging, starts via IDE heraus and is able to debug: OK - Case solved: XCode 15.3 + iOS 16.7.5 + iOS SDK 17.4 = Debugging possible I hope that can help another poor guy, who is getting crazy from the mysterious Apple moves. Edited April 25 by Rollo62 2 Share this post Link to post
David Schwartz 415 Posted April 25 (edited) There's also the problem that XCode upgrades may be required that cannot be installed without upgrading the OS. I stopped upgrading my MacOS a while back b/c it seemed like each time it would lock me out of apps that cost me a lot to update themselves to continue using -- if that was even an option. I have a 2014 Mac MIni running Mojave b/c there are several 32-bit apps that I use but can't update, and the next OS doesn't support any 32-bit apps. I have another one (2018) that's running Catalina and I won't update it either b/c of other things that break and will be expensive to update -- no free updates for these things. This is the machine I use to do my Delphi work on, inside of a VirtualBox VM, and now I can't even upgrade that to the latest version, although they seem to be supporting older versions pretty well. And with the switch to M-series chips, there's a BUNCH of apps I can no longer upgrade b/c they ALL require the latest version of the OS to run. XCode updates all seem to be tied to a specific version of the OS, and they don't maintain backward compatibility for older versions when they add new features to it. Which is why I'm mainly interested in working with TMS WEB Core to build web apps that run inside of web browsers and are not dependent on hardware or OS issues. Edited April 25 by David Schwartz Share this post Link to post
Rollo62 502 Posted April 26 (edited) 9 hours ago, David Schwartz said: There's also the problem that XCode upgrades may be required that cannot be installed without upgrading the OS. 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. Edited April 26 by Rollo62 Share this post Link to post
David Schwartz 415 Posted April 27 On 4/25/2024 at 10:20 PM, Rollo62 said: 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. This is exactly why I've chosen to go with TMS WEB Core as it runs in pretty much any web browser. It does not lock you into any particular hardware or OS version. If you need something specific, you can get a cheap machine and use it to build a REST service that the web app can call directly, or indirectly through your app's main service. There's also Crossover, which is a WINE-based containerized solution for running a Windows app in other environments that looks and runs as a native app. It's ok for one-offs, but publishers will need to see if its cost justifies the results. Share this post Link to post
![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}