Xcode

The Apple's default IDE is quite hostile to FPC, since it doesn't provide any source of "native" integration. In order for the compiler to be called a custom Run Script is needed to be used.

However it comes with some handy command-line tools that could be used for building projects. See Technical Note TN2339 for FAQ.

Command Line Utilities

xcodebuild

xcodebuild Man Page List all available SDKs

xcodebuild -showsdks

Build a project by it's (project directory) name and a specified sdk

xcodebuild -sdk iphonesimulator9.1 -project testProjGen.xcodeproj

instruments

The utility should only be ran via xcrun. Read manual page provided with Xcode command-line utilities installed.

The following command line runs Simulator booting the specified device. If the simulator is already running it would be rebooted with a the specified device, if it's different to the one already running.

xcrun instruments -w "%identifier%" -t "%template%"

• %identifier% - is a part of the device name or ID.
• %template% - if template is specified, then instruments doesn't return. If template is not specified (causes a warning on running) the instruments exists, leaving the device running.

simutils

An utility fo additional control over the simulator. Must be ran via "xcrun"

Lists all available devices in JSON format.

xcrun simctl list devices -j

Running without "devices" would list all devices. "-j" requests JSON format

Running an application on a booted device.

xcrun simctrl launch booted %bundle.id% 

"booted" can be replaced with an actual device id.

Running an application with waiting for a debugger (lldb).

xcrun simctrl launch -w booted %bundle.id%

The booted application will launch and pid for the application will return. For example:

bundle.id 1200

lldb

lldb has replaced gdb as a Apple main debugger utility. Unlike one might expect, it's NOT specific for LLVM or any llvm written program. It can as a "normal" debugger and debug non-LLVM based programs.

While debugger can launch a process itself, it's not applicable for using Simulator application. Since Instruments service typically runs the application first (with an option to wait for the debugger to attach to it). Thus the most important part of the debugger is being able to attach to the process.

The pid is a normal process within OSX environment and should be attached via lldb debugger, i.e.

lldb attach %pid%

Capturing Console Output

According to Apple any NSLog() call eventually ends up int "stderr". Since it's desired to see the output in Lazarus, it's necessary to intercept the stderr. On of the convenient ways is to redirect the output to a file. Once it's done the debugger could be released.

The way to redirect the stdout is to reassign unix file-descriptor within the debugged process to a file on the disk. For this close() function should be used. A file (descriptor) could be via open() function and reassigned to stderr via dup2().

LLDB allows to run commands within the debugged process by a number of commands (call, p, po). Here's an example of reassigning stderr to a file:

p (int) dup2 ( (int) open("/Users/dmitry/err.txt",2), 2)

Note, that each function has an explicit type-case before its usage (int). This is required for debugger without enough debug information provided. If debug info were present the call could look like this:

p dup2 ( open("/Users/dmitry/err.txt",2), 2)

For any non system unix function LLDB HAS to have the debug info available. DWARF format is preferred.

Run Script

• in order to return an error, the (bash) script must use "exit" command with non-zero value. FPC returns a non-zero value when compiling failed.
• do not specify "output files" of the script. Otherwise "Clean" will be required to make the script executed again

Debugging

Technical Note TN2239 - iOS Debugging Magic

Xcode project

Executable

Name of the executable is specified at buildSettings option PRODUCT_NAME.

Executable name should be specified at info.plist CFBundleExecutable

Name of the bundle would match the PRODUCT_NAME.