I solved the problem. I erased the iPad again. When I went to installed the beta profile, I realized that before I may have installed the wrong profile (iOS instead of iPadOS).
In both cases, the device was already in iPadOS beta 3. However, the second time, after I installed the right profile I was offered to download an update. I accepted and after that I was able to enable developer mode.
Post not yet marked as solved
The problem is not related to archiving. It occurs when the you launch the app in non-debug mode, which happens to be the case for Archive. But other ways to see the crash are, launching the executable from Finder (doesn't have to be the one archived), or uncheck the "Debug Executable" option in your the "Run" profile of your active scheme in Xcode.
I found a workaround, which is effective, but seems completely unrelated. This crash does not occur, if at some point before you display the VideoPlayer, an NSTextArea is displayed. But not just any NSTextArea. It must be loaded with an RTFD document. But not just any document, one that contains an image!
More details can be found here: swiftui-lab.com/videoplayer-bug
Post not yet marked as solved
I also found that in the official documentation all mention of macOS has been removed:
https://developer.apple.com/documentation/scenekit/sceneview
Does this mean SceneView is gone for good? I think this merits at least a comment in the Release Notes, so people can plan accordingly.
Anyone from Apple listening? Can you confirm, or deny... or just comment...
Post not yet marked as solved
Is there a way of generating the public interface from the command line, instead of having to go into Xcode and command clicking on the framework name. I need to automate a process and that would really help.
Post not yet marked as solved
The problem is due to a crucial bug in the tutorial. I'm surprise Apple did not correct it. Back when the tutorial was release, during WWDC2019 the tutorial worked fine, because the ForEach/List views had a specific behavior. However, by iOS13.0 beta 5, the behavior of those views changed and the tutorial stopped working properly. It seems they never updated it.
The change of the List and ForEach views was disclosed in the iOS 13.0 beta 5 release notes.
Basically, if you use a ForEach with static data or a range, the ForEach will read the data once. If it later gets modified, the ForEach won't update. This is what is happening in the tutorial. But before I go into the details of the tutorial, let me explain with a minimal example:
struct ExampleView: View {
@State private var array = ["apple", "peach", "banana"]
var body: some View {
VStack {
Button("Add Row") {
self.array.append("orange")
}
ForEach(array.indices) { idx in
								Text(array[idx])
						}
}
}
}
In the above example, indices is a range so taping on the "Add Row" button updates the array, but the view will not update. Indeed, that is what happens. To make it work, the code can be modified like this:
struct LandmarkList: View {
@State private var array = ["apple", "peach", "banana"]
var body: some View {
VStack {
Button("Add Row") {
self.array.append("orange")
}
ForEach(array, id:\.self) { fruit in
Text(fruit)
}
}
}
}
Now back to the tutorial problem. By introducing the change below, the problem is solved. Using firstIndex is not very elegant, but to demonstrate where the problem is and what makes it work, it is elegant enough. ;-)
ForEach(data, id: \.self) { v in
let index = data.firstIndex(where: { v == $0 })!
GraphCapsule(
index: index,
height: proxy.size.height,
range: data[index][keyPath: self.path],
overallRange: overallRange)
.colorMultiply(self.color)
.transition(.slide)
.animation(.ripple(index: index))
}
Maybe you could create a bug report with Apple and tell them their tutorial has a bug. It is an ugly bug for a tutorial aim at SwiftUI beginners.
Post not yet marked as solved
It seems if #available inside a @ViewBuilder is buggy. As a temporary workaround, you can wrap your LazyVStack with AnyView. As bellow:
struct ContentView: View {
	 var body: some View {
Group {
if #available(iOS 14.0, *) {
ScrollView {
AnyView(LazyVStack { content.padding(.horizontal, 15) })
}
} else {
List { content }
}
}
}
}
Post not yet marked as solved
Beta 5 has a new modifier to set keyboard type:TextField("Enter text", text: $val).keyboardType(.numberPad)
Post not yet marked as solved
Problem still present with Xcode 11 beta 4.
Post not yet marked as solved
Nice of you to create the list. If you accept suggestions for inclusion:TextFields do not have a way of setting their keyboard type.TextFields do not have the equivalent of UIKit beginFirstResponder and resignFirstResponder. That means there is no way of programatically setting or removing the focus from a text field.SecureField does not have a way of knowing when the field became active, or inactive (TextField does have onEditChange, but SecureField does not).Popovers as of beta3 seem to be broken.
Post not yet marked as solved
Hi dsabanin. No, Color.clear is not the way to go. Color.clear is just transparent. If you draw a rectangle with Color.clear over a read area, it will be read. I just so happens that during light mode, the default background is white and in dark is black. and using Color.clear just lets it through.
Post not yet marked as solved
Yeap, I saw the textContentType and I was very excited, but then I tested it and nothing happened. 😕Also note that UITextField uses UIKeyboardType to determine the keyboard to use, not UIContextType. For example, you can select UIKeyboardType.twitter, but there's no UIContextType.twitter. So it is not the same thing.Please create a bug report, I already did (FB6169169). The more the merrier, and make sure to refer to FB6169169.
Post not yet marked as solved
Problem still present in beta 2.
Post not yet marked as solved
At first I created a UIViewRepresentable to wrap a UITextField... and that works... There is, however, another option which takes advantage of the fact that it seems the SwiftUI TextField is actually already implemented as a UITextField. By observing the UITextField.textDidBeginEditingNotification I managed to change the keyboard. This is an ugly, ugly hack... that works. I leave it hear mostly for purely academic purposes... I don't think I would like to use this on production code:import SwiftUI
let dirtyWork = DirtyWork()
struct ContentView : View {
@State private var emailAccount: String = ""
@State private var twitterAccount: String = ""
var body: some View {
return VStack {
TextField($emailAccount, onEditingChanged: { if $0 { dirtyWork.keyboardType = .emailAddress } }).textFieldStyle(.roundedBorder)
TextField($twitterAccount, onEditingChanged: { if $0 { dirtyWork.keyboardType = .twitter } }).textFieldStyle(.roundedBorder)
Spacer()
}
}
}
class DirtyWork {
var keyboardType: UIKeyboardType = .twitter // some default
init() {
NotificationCenter.default.addObserver(self, selector: #selector(didBegin(notification:)), name: UITextField.textDidBeginEditingNotification, object: nil)
}
@objc func didBegin(notification: Notification) {
if let tf = notification.object as? UITextField {
tf.keyboardType = keyboardType
}
}
}
