Giuma is correct -- if syntactically correct code compiles and runs on the device or Simulator, then the failure of Preview is a bug, period. I can reproduce the problem in ten lines of code (not counting closing braces):
struct Outer {
static let hello = "Hello"
// Move MyText here and Preview compiles and runs.
}
extension Outer {
// With MyText here app compiles and runs correctly but
// Preview fails with "Compiling failed: cannot find 'hello' in scope"
struct MyText: View {
var body: some View {
Text(hello)
// This does work with Preview: Text(Outer.hello)
}
}
}
struct ContentView: View {
var body: some View {
Outer.MyText()
}
}
#Preview {
ContentView()
}
andrew.shoonya
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Since I posted, some people have experimented with commenting or ifdef-ing out parts of the Facebook SDK. The problem is how far to pursue the transitive closure of your edits.
Here is a link to a minimal set of diffs that worked for me. That is, the executable had no AdSupport or ASIdentifierManager references.
https://github.com/snorrsi/facebook-ios-sdk/commit/9d69d9ab0e510359311085def696c750c345037a
Same symptoms as for SmartPTT and Wizfinger: playing audio freezes the app, same Console errors, happens on iOS 14 on Simulator. I don't have test devices with older iOS, but some logging code I added to the app is reporting similar problems in live versions in the field.
This complaint shows up (with variants) all over the place. I am able to reproduce it in a from-scratch Xcode project, so I will be posting my code on Stackoverflow and asking DTS. I hope to have something more helpful to add here besides "Me too."
Ha, it only works until it doesn't. As in you can call it once or twice, but more times it will crash. My use-case is a one-time transition from a Portrait onboarding flow to a Landscape app. Setting (more like "telling") the device its new orientation makes the main app home view rotate to the correct presentation, even though the user is still staring at the physical device in Portrait mode. But.. try to go back again and you will quickly find yourself (if debugging) in the middle of unfamiliar (to me, I stopped after the 6502) opcodes.