You are doing a lot in the .onChange block. To fix the compiler error, I recommend creating a function to calculate the value of P_Sprint and call the function in the .onChange block. Breaking up the calculations into smaller chunks will also help you fix the compiler error and make the code easier to understand.
If the code was working in Xcode 15.2 and you want to publish your app without making the code changes, then install Xcode 15.2. Build, archive, and submit your project in Xcode 15.2. Apple doesn't require Xcode 15.3 for App Store submissions.
Use the site Xcode Releases to find Apple's download links for all Xcode versions.
https://xcodereleases.com
No one can give you an answer until you show the code that is causing the compiler error.
Post not yet marked as solved
Use the FileWrapper class to store your document as a package of files and folders that appears as a single file in the Finder. The following article provides an introduction to working with file wrappers in a SwiftUI app:
https://www.swiftdevjournal.com/using-file-wrappers-in-a-swiftui-app/
Post not yet marked as solved
The following article shows ways to get around your issue.
https://www.swiftdevjournal.com/dealing-with-failed-to-prepare-device-for-development-error-message-in-xcode/
If the workarounds in that article don't work, you will need to find a device running an older version of iOS to run your project on your Mac.
I had a similar issue, which you can see in the following post:
https://developer.apple.com/forums/thread/740539
It turns out I had to add a Mac build to my app in TestFlight and get the build approved for external testing to get the products to fetch properly.
Post not yet marked as solved
According to the following article:
https://serialcoder.dev/text-tutorials/swiftui/navigation-view-style-in-swiftui/
Use the columns navigation view style to have two panels side by side on iPhones with screens big enough to show two panels.
NavigationView {
…
}
.navigationViewStyle(.columns)
I don't have any simplified approach for you. I can tell you two things.
First, to pass a view model to a SwiftUI view, do the following:
Have the view model conform to ObservableObject.
Add @Published properties in the view model for any properties where you want the view to update when the property's value changes.
Use @StateObject in the view that owns the view model.
Use @ObservedObject in the other views where you want to use the view model.
Second, avoid nesting observable objects. SwiftUI views may not update properly when a property in a nested observable object has its value change. If you are unfamiliar with nested observable objects, read the following article:
https://holyswift.app/how-to-solve-observable-object-problem/
I don't see anything obviously wrong in your code. The only possible problem I see is a coordinate system problem where the values of the touch location may not be what you expect because the view and the scene have different coordinates.
Set a breakpoint at the following line of code:
let node:SKNode = ourScene.atPoint(location)
Check if location is where you expect it to be.
I made a mistake in my answer. The @ObservedObject property wrapper is for SwiftUI views. You can't use it in a view model. The following declaration:
@ObservedObject var dataManager = DataManager()
Should be something like
@Published var dataManager = DataManager()
I am not sure what you are asking in your second response. You described what you are trying to do but didn't ask a question.
Bindings are for SwiftUI views. Using @Binding in a view model isn't going to work. Creating a binding like Binding<Bool> in a view model isn't going to work either.
For passing data from a view model to a SwiftUI view, you are on the right track with the following code in ContentViewModel:
class ContentViewModel: ObservableObject {
@ObservedObject var dataManager = DataManager()
@Published var isOn: Bool = false
}
Have the view model conform to ObservableObject. Use @Published for any properties where you want the view to update when the property's value changes. The view that owns the view model uses the @StateObject property wrapper, like you have in your content view.
@StateObject var viewModel = ContentViewModel()
Use the @ObservedObject property wrapper to pass the view model from the content view to other views.
I am not sure why the content view model needs its own isOn property. Can't it use the data manager's isOn property?
Post not yet marked as solved
For the Swift Student Challenge, either create an App playground in the Swift Playgrounds app or create a Swift Playgrounds App project in Xcode. That will give you a playground or project that meets the challenge's eligibility requirements.
https://developer.apple.com/swift-student-challenge/eligibility/
Post not yet marked as solved
Starting April 29 Apple is going to require Xcode 15 for App Store submissions. Xcode 15 requires macOS 13+.
https://developer.apple.com/news/?id=fxu2qp7b
The chances are high you won't be able to submit apps with that MacBook Air.
I recommend buying a Mac with an ARM processor. ARM Macs are going to be supported longer than Intel Macs.
Post not yet marked as solved
The .fileImporter modifier isn't for opening your SwiftUI app's documents. It's for opening other types of files in your app. The document struct's init that takes a ReadConfiguration is for opening your app's documents, either from a document picker (iOS) or by choosing File > Open (Mac).
Instead of using your document struct's init that takes a ReadConfiguration, write a function to process the JSON that takes a URL as an argument. Pass the URL the file importer gives you to the JSON processing function.
Post not yet marked as solved
I am not sure if the Swift Playgrounds app has been updated to support SwiftData, but the following article shows how to use Core Data in a Swift Playgrounds app:
https://www.cephalopod.studio/blog/build-an-app-on-ipad-with-swift-playgrounds-and-core-data
Post not yet marked as solved
I have never had a problem with my projects when moving to a new version of Xcode.
Create backups of your projects before updating so you have a copy you can go back to if you do encounter a problem when updating to Xcode 15.
