iOS build tutorial results in: `Not implemented: TextInput.set_on_gain_focus`

Describe the bug When following the iOS build tutorial, I’m facing the following when running the simulator. The app opens then crashes with the following in the terminal:

2022-11-22 00:10:21.279 Df Hello World[78988:37018d] (_ctypes.cpython-39-iphonesimulator.so) [iOS] Not implemented: TextInput.clear_error()
2022-11-22 00:10:21.280 Df Hello World[78988:37018d] (_ctypes.cpython-39-iphonesimulator.so) [iOS] Not implemented: TextInput.set_on_lose_focus()
2022-11-22 00:10:21.281 Df Hello World[78988:37018d] (_ctypes.cpython-39-iphonesimulator.so) [iOS] Not implemented: TextInput.set_on_gain_focus()

To Reproduce Steps to reproduce the behavior:

1. Follow the Briefcase tutorial
2. Follow the iOS build tutorial (5)
3. Run briefcase run iOS -u (Selecting any ios simulator)
4. See error

Expected behavior The app should run and provide a simple dialog.

Screenshots

Environment:

• Operating System: MacOS
• Python version: 3.9
• Software versions:
  • Briefcase: 0.3.11
  • Toga: 0.3.0.dev39 (toga-cocoa)

Additional context The MacOS build works fine.

[freakboy3742]

Eureka! I’ve found the problem.

In the recent iteration of updates to the Python support packages, we made some changes to the platform module that mean platform.machine() can be used to report that you’re on an iPhone, or an iPhone simulator.

However, Rubicon uses platform.machine() as part of an identification check to see if you’re on x86_64 hardware.

The change to the platform module has broken the x86_64 check, and as a result, Rubicon is using the wrong message passing API to invoke methods that return large structures (obc_msgSend_stret). This doesn’t affect M1 because the CPU identification check is slightly different.

If you had an older support package when running through Xcode, that might explain why the app would run; an older support package would have the older platform implementation.

I’m working on a fix for Rubicon ObjC now.

[freakboy3742]

More investigation: It turns out the problem isn’t the deprecation (at least, that’s not the cause of the problem here); the x86 simulator is currently crashing on any property that returns type NSRect. This appears to only be a problem in the emulator; macOS apps are able to access properties of type NSRect (e.g, view.frame) without difficulty.