Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.

I would not recommend signing a program in place of someone else since it is your developer account which will be tied with any incident potentially linked with the application. Not that this is likely but it is probably better to work this out with the author/owner first to make sure everything is agreed upon in the first place.
Definitely do not use your work account, that would likely put your in a risky position vis a vis your employer.

Also, as far as the Apple Store is concerned, Apple is still as stingy as ever when it comes to accepting emulators. It looks like they only accept them when the emulator owner also has the copyrights to the emulated machine software and/or when they are big players (SEGA, etc).

Unrelated:
I just got Oricutron's sources from https://github.com/pete-gordon/oricutron and it does not compile straight out of the bat on macOS, I see that there are a few frameworks which are not needed by the Xcode project but not included by default: OpenGL, SDL, XCTest (likely added by Xcode when it upgraded the project settings).
Note: I also fixed the .pch issue noted in a previous post. Not sure how that ever compiled for the original author.

Should they not be included in the git repository directly? This would save quite a bit of hassle on macOS.

Generally speaking, the repository is missing information about how to rebuild the project for the various platforms.
Like for example, I've no idea how the Windows version was built, because there's no visual studio solution, maybe it was made with Clang/LLVM, or mingw32, ... no idea

It might say more about my abilities than anything else, but I find that keeping up to date with Xcode is a worthwhile aim in itself just because the surrounding tooling is always improving. E.g. the latest version of the runtime analysis tools pointed out the undefined behaviour in (heavily simplified):

I am fully aware in the abstract of why that's undefined behaviour and also why it'd never have any effect on any platform I'm ever likely to test on, but being formally correct is always better especially at the cost of only a single modifier and apparently I wasn't smart enough to avoid the error of my own volition.

Static analysis tools are definitely a plus.
I guess the error in your code is the use of a signed integer which gives undefined behavior when shifted?

Regarding Xcode it was years since I last touched it and I recall it not being a pleasant experience, the UI was clunky, unintuitive and inflexible compared to Visual Studio and the damn thing was crashing left and right every 15 minutes. Thankfully things look like they improved significantly since.

When we worked on Lego Minifigure Online, the biggest problem we had is that there was some pretty hard dependencies between the version of iOS apis you can develop for, the version of XCode to use, and the version of OSX Xcode accepts to run on.

It's an absolute versioning nightmare, basically if you have to upgrade all your macs to run the version of xcode that allows you to build the ios version... it means you don't have any mac running an older version of OSX, making it impossible to test regressions of the OSX version of your application :p

Sorry, to be clearer about prejudice: my day job for almost a decade was iOS development, both in iOS-first organisations where everything tended to be smooth and easy and in the furthest possible thing you can get from an iOS-first organisation, where there was a natural desire to plug iOS development into an existing build system and therefore all of Apple's, ummm, 'unique' decisions suddenly become roadblocks. Just a hassle all around. I was already an Apple developer as a hobby as long ago as OS X v10.2 so, since Xcode was introduced in 10.3, I can legitimately say I've used every single version. But I didn't keep notes.

Nowadays I'm a Linux developer by day. So all that is olden times talk.

The hard link in versioning isn't exactly as bad as the above makes it sound: any version of Xcode can develop for any version of iOS no newer than it for which the compiler can still target the CPU architecture, and you can virtualise old versions of OS X going back to 10.4 which was the first version on this side of the Intel transition. It's the other direction that's a hassle: the general rule is that as soon as a version of macOS stops being the most current, it has a year left of being able to run the latest Xcode and therefore being able to target the latest iOS and macOS. I think Apple's hoping that strictness on developers will contribute to its desire to compel everybody always to upgrade. It probably does, but it is an obstacle.

Regardless, I think we're agreed on the main point: keeping your Xcode project up to date implies quite a lot of additional effort. Probably more than just being a casual Mac maintainer.