Re: Minimal Swift/iOS Delivery Example?

Hi Yacin,

Summer days steal my screen time, and I am returning to this thread.


> On Aug 7, 2025, at 21:35, yacin (as yacin at defmacro dot cc) 
> <[email protected]> wrote:
> howdy Matthew
>
>> On Aug 1, 2025, at 1:04 AM, Matthew Sinclair-Day (as msd at 
>> sinclair-day dot com) <[email protected]> wrote:
>> 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:
>>
>> <snip>
>>
> thanks for the helpful suggestions! i clearly didn’t read the 
> LispWorks header file closely enough, because 1 actually means it was 
> successfully initialized and all other values means it failed. it was 
> in fact initializing properly.
>
> the next hurdle i ran into was how to call my code from Swift. i had 
> sent another message to the HUG, but it included enough code it was 
> rejected due to size. i reached out the LispWorks support and they 
> were able to help me out. the tl;dr here is i was defining the methods 
> for my LispWorks-generated class with an @objc protocol and trying to 
> call them directly. these symbols are _not_ present in the delivered 
> .o file. this should have been obvious from the provided example, 
> which does everything dynamically based on the string naming the class 
> and a selector naming the method. for anyone following along at home, 
> it looks something like this in Swift:
>
> @objc protocol FooServerProtocol {
>     func setDB(path: NSString)
> }
>
> ...
>
>         guard let serverClass = NSClassFromString(“FooServer") as? 
> NSObject.Type else {
>             print("FATAL ERROR: The ‘FooServer' class was not 
> found.")
>             return
>         }
>
>         let instance = serverClass.init()
>
>         let selector = #selector(FooServerProtocol.setDB(path:))
>         if instance.responds(to: selector) {
>             instance.perform(selector, with: "path/to/server.db")
>             print("Set DB path")
>         }
>
> a little clunky, but it works like a charm now!

It's good to hear this is working. I expect to be on a similar path 
someday, and now I have a heads-up about how the bridging works.

>> 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?
>>
> good to know it’s a common problem. the :IOS-DELIVER was added so it 
> would build/initialize properly without that functionality for now. i 
> cannot recall the error exactly, but if DEXADOR (and thus CL+SSL) was 
> included, the app either failed to compile or even startup.
>
> now i’m currently fighting with the app suspending, presumably 
> trashing the memory in Lisp land, and causing a hard crash when the 
> app is resumed. it works fine on a fresh Xcode deploy, but trying to 
> re-open the app it crashes immediately. if folks have ideas here, 
> i’m all ears, but i may just reach out to support again as it 
> isn’t covered in the docs/examples from what i can tell.
>
> cheers
>
> yacin

Did you work through the problems with the Lisp runtime crashing?

I have limited experience with SwiftUI and none with writing a complete 
SwiftUI app. But I assume it follows a similar lifecycle to UIKit: iOS 
notifies the app via its delegate when moving it to the background, 
terminating it, or activating it, etc. That makes me think that in the 
handlers for some of these events, the app should shut down and release 
the LW runtime; in others, LW should be initialized and started.

About cl+ssl: I note in the documentation for LW's "comm" package that 
it integrates with both OpenSSL and Apple's Security Framework on iOS 
and macOS. This feature made me think that perhaps there is a way to 
leverage "comm" to solve the DEXADOR problem (e.g., direct cl+ssl to 
whatever OpenSSL lib LW uses), replace DEXADOR with "comm", or 
extend/hack the USOCKET layer to leverage LW's crypto support and drop 
cl+ssl.

Matthew