Re: Minimal Swift/iOS Delivery Example?

was finally able to fix this. turns out my method of only calling LispWorksInitialize once wasn’t working, and when i made it work properly it stopped crashing on resume:

func initializeLispWorks() {
    if !lispInitialized {
        let result = LispWorksInitialize(CommandLine.argc, CommandLine.unsafeArgv)
        if result == 0 {
            print("❌ Failed to initialize LispWorks Runtime.")
        } else {
            print("✅ LispWorks Runtime Initialized Successfully.")
            lispInitialized = true
        }
    }
}

silly me, but i got all my issues sorted out. thanks for rubber ducking :)

cheers

yacin

> On Aug 26, 2025, at 10:13 AM, yacin (as yacin at defmacro dot cc) <[email protected]> wrote:
> 
> howdy Matthew,
> 
>> On Aug 20, 2025, at 9:32 AM, Matthew Sinclair-Day (as msd at sinclair-day dot com) <[email protected]> wrote:
>> 
>> Hi Yacin,
>> 
>> Summer days steal my screen time, and I am returning to this thread.
>> 
> as they should!
>> <snip>
>> 
>> 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.
>> 
> almost all of them, but there’s still one lingering around and i suspect it’s exactly what you’re describing here. on my @main i have something like this:
> 
>         .onChange(of: scenePhase) { oldPhase, newPhase in
>             switch newPhase {
>             case .active:
>                 print("App became ACTIVE, creating LispWorks server instance.")
>                 initializeLispWorks()
>                 lispWorksGlobal.createServerInstance()
>             case .inactive:
>                 print("App is INACTIVE.")
>             case .background:
>                 print("App went to BACKGROUND.")
>             @unknown default:
>                 print("An unknown app phase occurred.")
>             }
>         }
> 
> this wasn’t required to address my initial crash, which i think was just due to how i was handling the strings i received from the Lisp runtime. now it’s definitely segfaulting when re-calling LispWorksInitialize, so i suspect i need to appropriately tear down when the app gets backgrounded. do you know how i can release the LW runtime? there are only two functions declared in LispWorks.h and the other doesn’t seem related to teardown. i assumed it was from the code in lispWorksGlobal, but the backtrace clearly shows it’s in the initialization function:
> 
> 0   cross my <3.debug.dylib       	       0x102cdb1b4 lispcode__S___D___-___D___I___R__ + 468
> 1   cross my <3.debug.dylib       	       0x1029efe30 lispworks_main_with_data_block + 84
> 2   cross my <3.debug.dylib       	       0x1029ec22c LispWorksInitialize + 44
> 3   cross my <3.debug.dylib       	       0x1029b402c initializeLispWorks() + 56
> 
>  it’s a bit tricky, since this only happens when i wait a rather long time after the app has been backgrounded and open the app up again.
>> 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.
>> 
> i did do just this and it works great! 10 lines of Lisp to recreate a simple HTTPS GET with COMM when i’m deploying to iOS and i’m back in business.
> 
> cheers
> 
> yacin
>