Closed meichthys closed 1 year ago
Those "Not implemented" messages should be non-fatal. Are you sure there aren't any other errors in the terminal?
To that end, running briefcase run iOS -u --log
will force Briefcase to create a logfile you can upload. Additionally, if you click Report in that crash dialog modal, providing that log from Apple may help too.
@mhsmith Here's the terminal output:
@rmartin16 Here's the apple report log:
Adding potentially relevant cross reference: https://discord.com/channels/836455665257021440/836455665257021443/1042526753677123745
I'm not able to reproduce this; the tutorial is running fine for me.
The logs you've provided suggests the app is segfaulting at some point in the app startup - possibly when the main window is being created. Unfortunately, it's very difficult to diagnose a segfault without a reproduction case.
Could I get you to provide:
Could I also ask you to delete the iOS directory that briefcase generated in your project folder, then run briefcase run iOS --log
, and send us the log file it generates (the actual briefcase-....log
file, not a copy of the terminal output).
@freakboy3742 Here's the logs after removing the iOS directory and running briefcase run iOS --log
One thing that is different in my setup is that i'm using pipenv & pyenv.
Looking at the logs it does indeed look like pipenv or pyenv is messing with the path so that briefcase isn't able to find the pyproject.toml or other resources :/
Bracing for impact! . I guess I need to go back to built-in python tools..
That's a failed build caused because you've run Briefcase from the wrong directory (or you've deleted more than just the iOS folder). It's got nothing do to with pipenv, pyenv, or the recent repo reorganisation.
I'm pretty confident my project structure is correct:
I just nuked the beeware-tutorial directory and walked through the tutorial again without any luck. Here's a more useful(?) log: briefcase.2022_11_23-18_15_39.run.log
I didn't say your project structure was wrong - I said you were running briefcase
from the wrong directory. You were running the beeware-tutorial
folder, not the helloworld
folder; and as a result, the error was exactly what it said - there wasn't a pyproject.toml
in your current directory.
In this second run, you've invoked it from the correct folder, and so the build has completed.
Looking at that log, the one notable difference I can see is that you're on x86 hardware (I previously tested on M1); I'll fire up my x86 test machine and see if I can reproduce the problem you're seeing.
I've been able to reproduce this problem on my x86 test machine; I'm investigating the cause now.
Progress update: there's 2 issues going on here.
The root cause is a deprecation in iOS - iOS has deprecated the UIScreen.mainScreen
API in favour of a newer UIWindowScene API. It's not clear when this deprecation was announced, but it appears it took effect in iOS 16.1. They've removed this API in the x86_64 emulator; however, it's still available on the M1 emulator.
Ordinarily, this would be reported as a AttributeError
by Rubicon; but then we hit the second issue - it appears there's something going on with memory handling when an attribute lookup fails. A deliberate bad attribute lookup on M1 is giving me oddly corrupted log output:
File ".../Hello World.app/app_packages/rubicon/objc/api.py", line 888, in __getattr__
raise AttributeError('.: Ä‘m has no attribute ®CV∏06'
AttributeError: rubicon.objc.api.ObjCInstance UIScreen has no attribute foobar
I'm guessing this is accidentally working on M1, and is segfaulting on x86_64.
I've worked out what's going on with Rubicon - it's actually the std-nsLog wrapper that is the issue. The recent 1.0.2 release included an optimisation to the way messages are logged; however, that optimisation has resulted in log messages losing escaping; as a result, raise AttributeError("%s.%s does not exist " % (...))
causes a bare %s
to be logged, and NSLog tries to fill it with the memory buffer.
Ironically, the Rubicon-obj mainline no longer triggers this error, because it now uses f-strings rather than %s
formatting.
So - the immediate workaround for the rubicon issue is to downgrade to std-nslog 1.0.1. I'll publish an updated std-nslog shortly.
The UIScreen deprecation is a larger issue that will require a significant patch to toga-iOS.
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.
To follow up here, if I open the project in Xcode manually and Build/Run, it runs fine in the simulator and on my personal iOS device. Note: it did fail to build in Xcode until I selected a "Signing Team" inside Xcode > Signing&Capabilities
Failing to build until you select a signing team is expected; that's a requirement of running on device.
Succeeding on device is also consistent with the behavior I'm seeing; I'm only seeing the error on x86 hardware.
I'm intrigued that you're seeing success inside Xcode, though; I wonder if it that might indicate a debug vs release configuration issue.
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.
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:
To Reproduce Steps to reproduce the behavior:
briefcase run iOS -u
(Selecting any ios simulator)Expected behavior The app should run and provide a simple dialog.
Screenshots
Environment:
Additional context The MacOS build works fine.