I’m back to trying to learn some iOS development. I have a test iOS project on Windows that I am trying to deploy to the simulator on my (M1) Mac Mini. I believe that debugging is still not working with this configuration, so instead I just want to deploy and run without debugging. From Visual Studio, I’ve tried menu option “Build => Deploy Solution”, and “Debug => Start Without Debugging”. In both cases it generates the following error::
Starting deploy to Crossbox Server 192.168.27.49
Running /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/Contents/MacOS/Simulator -CurrentDeviceUDID 9853D113-AE78-4B5F-843C-CAC56026F560
Waiting for device to boot.
Waiting for device to boot, current state: Shutdown
Device booted ok.
Failed to deploy to CrossBox Server 192.168.27.49: Could not determine path for executable or app bundle.
I think I was seeing something similar in Water, but I rebooted both the Mac and Windows, and now things seem a bit different there. Although Crossbox seems to be connected, the Deploy w/o Debugging option is disabled, as is Run w/o Debugging. The “Run” option does work (it connects to my (M1) Mac and launches the simulator), but it gets stuck on the launch page I think because it is trying to debug, which I believe is a known issue - here’s the last several messages there:
Device booted ok.
Uploading iOSBasic2.app to 192.168.27.49.
Running /usr/bin/xcrun simctl install 9853D113-AE78-4B5F-843C-CAC56026F560 "/Users/alovhaug/Library/Application Support/RemObjects Software/EBuild/CrossBox/Clients/WIN10CMIKU/2C5FADE01ED78173E9D18532A1C40C6B3F43F00D/Toffee-iOS/iOSBasic2.app"
Running /usr/bin/xcrun simctl launch -w 9853D113-AE78-4B5F-843C-CAC56026F560 com.codepoetrysoftware.iOSBasic2
simctl launch: com.codepoetrysoftware.iOSBasic2: 803
simctl launch: exit code 0
Connecting
Port is 54464
Running /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver -f16 --log-file /dev/stdout 0.0.0.0:54464 --attach=803
debugserver-@(#)PROGRAM:LLDB PROJECT:lldb-1200.0.44
for arm64.
detected architecture: arm64
Attaching to process 803...
Trying to attach to a translated process with the native debugserver, exiting...
My 3 questions from this are:
What could be the cause of the error I am seeing in Visual Studio when I try to deploy?
Why would Run w/o Debugging and Deploy w/o Debugging be disabled in Water?
Are these issues likely due to the fact that I’m using an M1 Mac Mini? If so, perhaps I need to just abandon working in Windows for now, and focus my attempts to learn iOS development using Fire.
The only known issues here is the launching on the Simulator on M1 (and that one is indeed M1 specific). There’s two issues here that come together:
we can’t link arm64 simulator binaries yet (that’s our bug, and we’re investigating; (bugs://85346: Problem linking Toffee iIOS/Sim/arm64)
while we can link x86_64 simulator binaries fine, debugserver refuses to attach to them (“Trying to attach to a translated process with the native debugserver, exiting…”), even when i explicitly tell it to run in x86_64 — something that works fine for macOS apps. I’m not sure if that’s something we’re doing wring or (more likely), just something Apple doesn’t support.
The solution here is to fix the 85346 issue so you can build native arm64 Simulator binaries; i’ll see if i can get this priority over the next couple of days.
Note that this should affect only the debugging; deployment should work fine (for both architectures, i believe).
That is as designed, as i recall. We don’t suppoprt launching iOS apps w/o debugging, at this stage; the only options availabkle shoulf be “deploy” (and launch tyourself), or “debug”. This is for historical reasons; i think we could start supporting launching outside of the debugger with the latest toolchain, so i’ll log a separate issue for that.
As for the original error
Failed to deploy to CrossBox Server 192.168.27.49: Could not determine path for executable or app bundle.
that is odd; this would idicate a missing FinalOutput.xml (this is generated by the build), or bad info inside it. Does this error persist, in VS, or do both VS and Water now show the (expected) “Trying to attach to a translated process with the native debugserver, exiting…” error?
I’m still getting the “Could not determine path…” error in VS, unless I leave the simulator going on the Mac. In that case it seems to try to restart the simulator with bad results - it closes the previous device but doesn’t start a new one, and I get the error “Simulator process went away before device could reboot”. I can replicate that pretty consistently from VS - unless I quit the Simulator application on the Mac every time.
I appreciate it, but I certainly wouldn’t want you to prioritize this over issues affecting developers building real applications, since I’m just experimenting and learning right now.
Where would I expect this file to be located? All the project folders I’ve looked in so far do not seem to have this file.
This makes me wonder if I’m doing something wrong, but then again this particular scenario is not in wide use with your existing user base.
Curious. I’ll try and have someone form the VS team see if they can reproduce this. Consistently onmkly in VS, not Water though?
hmm…
this would be in the Obj folder, %APPDATA%\RemObjects Software\EBuild\Obj\, and then a sub-folder for your project. The easiest way to find it is to look at the build log, in the Generated Files section.
For what it is worth, I found the folder, and in Visual Studio performed a Clean, and then a Build, and it seems to have created a new FinalOutput.xml file. Copied the file to a new folder, then opened Water and did the same thing - Clean, then Build. Then ran a comparison against the two versions against the two files. The one on the left is the version Visual Studio generated, the one on the right is the one that Water generated:
Hmm, it seems VS is building for Device, but then trying to run for Simulator… If you look at the build log, does that match? @viktoriad, any idea whats going on here (this also feels oddly familiar, as if I logged something similar last week or so, either from you or someone else, that VS builds the wring destination)…
I assume a Simulator is selected as active device?
