You could try to figure out which object is crashing, by manually del'ing them, one at a time. (my guess - services are getting del'd before delegates). Then, add an extra retain() for the offending objects.

Alternatively, maybe try setDelegate_(None) on everything that takes a delegate, to disentangle things.

Trying to run incrementally more code after the crash to find the culprit failed, as Pythonista will crash if I execute just an empty file.

Setting delegates to None has not changed things.

Manually deleting either the session object or the advertiser object both cause a crash after a successful connect, but do not cause a crash if I do the deletes after running the server code without a connection.

@JonB, as this is the code that gets run on an invite, which seems to be the crucial point causing the crashes, and as I understand next to nothing about it, I have to ask if there is anything you see that messes things up?

Hmm, okay:
can you print (console) .retainCount() for the advertiser and session objects, for the case when no invite happens, then after the invite occurs?

What I am wondering is if something is getting released by the invitationHandler -- that bit of code is taking the block that is passed to the delegate method, turning it into an actual ObjCBlock, then invoking it.

One thing you could do is override the __del__ method of the suspect ObjCInstances -- maybe set up logging to a file in your script, then insert a logger.debug(self), that way we can see which object is the culprit.

Next, you could try first calling retain() on those instances -- that may cause a memory leak, but probably not a crash.

my guess was that something in the MPC framework still holds the reference and uses this invitation handler but the pythonista garbage collector does not know this because it only knows about references in your python programm. Thus when the python gc deletes it, and after that something in the apple mpc framework wants to call it, it will inevitably crash.

EDIT:
instead of someglobalscopedobject you could also use something like that to make it able to be reentrant

Yes that looks promising. I just uploaded my work on this for you at github. It doesn't crash and is completely reentrant. The idea was to make an simple API which games and other apps can import. But I did not work on it recently. When I saw your post that you too want to build an API I thought you might want to have a look. https://github.com/mithrendal/pythonista_mpc

@robertiii be aware, my code on github is still unfinished. I did this some months ago to proof that MPC is really working in Pythonista . Thats what the code does well. I uploaded it then for @mikael as an working example. But it does not yet serve as an solid and simple API, a lot of polishing and refactoring is still needed here. I am still at it, but my time for it is restricted so don't expect a finished API very soon. Of course you decide, but I would wait for @mikael 's Grand Python Simplyfication !!! That is what I am also looking forward to ;-) because he has already done some great APIs for pythonista (see here https://github.com/mikaelho).

This is a functional chat, even though the prompts and incoming messages tend to get messily mixed up.

You can also run the multipeer.py file to try out a cleaner Pythonista UI version of the chat, which demonstrates sending dicts as the message content, and acts as the best 'how-to guide' at the moment.

Docs still need some significant work. All testing and comments highly welcome.

Noted that shutting and restarting the UI chat client leads to duplicate messages being received, at least with 3 peers, and general instability. I will try including the checks to not re-create classes when already available.