Re: Minimal Swift/iOS Delivery Example?

On 25 Jul 2025, at 20:51, yacin (as yacin at defmacro dot cc) wrote:

> howdy HUG,
>
> does anyone have a shareable example of delivering for iOS in a 
> SwiftUI application? i think i’ve gotten as far as i can based on 
> the ObjC delivery LispWorks' docs and searching the internet, but 
> i’m unable to get things properly working. i have an existing iOS 
> app and an existing CL codebase for the backend logic that i’m 
> trying to merge. everything builds, my library is linked, and the app 
> launches as expected, however, Lisp initialization fails. here’s 
> what i’ve done so far:
>
> * build the .o files for delivery (ios-deliver.lisp is attached).
> * add a bridging header that has #include “LispWorks.h”
> * include the LispWorks.h file from the Othello example
> * ensure the .o, LispWorks.h, and bridging header paths are included 
> in Xcode’s build settings for Other Linking Flags, Header Search 
> Paths and Objective-C Bridging Header settings, respectively.
> * added the following Swift function to initialize Lisp and call it in 
> the main app’s init() method.
>
> func initializeLispWorks() {
>     let result = LispWorksInitialize(CommandLine.argc, 
> CommandLine.unsafeArgv)
>
>     if result == 0 {
>         print("LispWorks Runtime Initialized Successfully.")
>     } else {
>         print("Failed to initialize LispWorks Runtime.")
>     }
> }
>
> the app builds successfully, and i can confirm that it is linking my 
> delivered .o file from the build log. everything starts fine, but i 
> see the message for failing to initialize the LispWorks runtime. any 
> ideas? any way i can debug this more? i already have the delivery 
> level set to 0.
>

I don't have experience integrating LW with iOS, but iOS development is 
a familiar domain. Here are some questions and approaches that might (or 
might not) be helpful to debugging:

- CommandLine.argc and unsafeArgv are what values—are they null? And 
if so, does that matter?

- Is the result code returned from LispWorksInitialize anything 
meaningful or even not "1"?

- Can you set a break point in Xcode and inspect the frame before, 
during, and after the call to LispWorksInitialize for anything 
interesting? Were any Objective-C classes/objects created on the CL 
side? Did it fail immediately or after some time?

- Does the initialization of the LW runtime and your code do anything, 
like network or file I/O, that could fail or that could cause app 
sandboxing to shoot down? For that matter, are you missing app 
entitlements? Does the log on the iOS device show anything useful?

- Are you linking against the wrong .o, like one built for the 
simulator, not the device? I assume not, but things happen.

- Perhaps, for the sake of isolating and eliminating possibilities, 
side-step the Swift bridging and initialize the LW runtime in main() in 
Objective-C land, a la the documentation. If it works, well then....

- Another approach might be to start from the basics and build up step 
by step. Deliver a no-op do-nothing image that should always succeed 
initialization. If that works, you can assume that your iOS integration 
approach should be sound. Progressively re-add functionality and 
dependencies into the image until it breaks again.


> note: that the delivered library originally contained a dependency on 
> CL+SSL, which initially failed due to not being able to find 
> libcrypto.dylib. this is only for a small piece of functionality that, 
> for now, i can eschew, which is not brought in anymore if :IOS-DELIVER 
> is included in *FEATURES*. once i did this, i no longer saw any errors 
> while trying to initialize Lisp, but it still fails. if anyone has 
> advice for including CL+SSL (in order to include DEXADOR for HTTP 
> requests) on iOS, that would be nice, but it should be easy enough to 
> directly do that in Swift and pass the returned HTML to Lisp to work 
> without requiring DEXADOR.
>

Problems linking against libcrypto and others on iOS and macOS are not 
new. I am fuzzy on the details, but you might try linking against a 
specific version of libcrypto.dylib. Or you might need to build and 
bundle your own OpenSSL; perhaps, there is a Swift package that does the 
heavy lifting? For some reason, I am under the impression Apple wants 
apps to bring along their copies of these sorts of dependencies.

Could the removal of CL+SSL on :IOS-DELIVER be breaking something in 
your CL code and causing LW initialization to fail?

Matt

> cheers
>
> yacin
>
>