Post not yet marked as solved
I have absolutely no idea, but at some point (for my production app) it began working again. And now today (on an apple documentation sample app), it’s back. No idea what previously made my production app work - just tried one more build and it magically worked.
This is incredibly frustrating, as last time when this occurred, I lost several days of productivity.
Today, I’m trying to build the app from
developer.apple.com/documentation/avfaudio/audio_engine/audio_units/creating_a_custom_speech_synthesizer
and the same error occurs again.
Today, I’ve tried building with GA Xcode 15.0 (15A2240d) plus with Xcode 15.1 beta (15C5028h).
As before, other apps can be built & installed to my iPhone using either version of XCode - but this one app cannot be installed on my iPhone.
And also as before, I’ve deleted the app and restarted everything multiple times. I’ve cleared out both /Users/me/Library/Developer/Xcode/DerivedData/ as well as /Users/me/Library/MobileDevice/Provisioning Profiles/.
Nothing works.
I suspect that the error message is a red herring, but as a result I’ve no path forward.
Here’s a simple implementation of my Graph object. Basic ideas are just this:
the Graph class conforms to @ObservableObject and contains an @Published Float called position. My app can manipulate this and RealityKit will reposition the object based upon this.
the renew() function creates an AnchorEntity, loads a jpg to be used as a Material, creates a box Entity using .generateBox(), and then adds this as a child of the anchor
renew() also resets / re-creates an array of all Entities used (called all) by appending each child of the anchor defined in step (2). I manually maintain this array to facilitate app logic outside of the RealityView update: closure
Again, this is a simplified implementation but it shows how I’m manually creating the RealityView scene with each call to the update: closure. Surely this isn’t the most efficient way to update a scene, but it’s all I can figure with existing documentation.
import SwiftUI
import RealityKit
class Graph: ObservableObject {
// step 1: define an @Published var
@Published var position: Float = -1.0
var anchor: AnchorEntity = AnchorEntity()
var all: [Entity] = []
static let singleton = Graph()
init() {
renew()
}
func renew() {
// step 2: manually create the scene
// create / recreate anchor
anchor = AnchorEntity()
// load a jpg to paint the cube
guard let resource = try? TextureResource.load(named: "gates") else {
fatalError("Unable to load texture.")
}
var material = UnlitMaterial()
material.color = .init(texture: .init(resource))
// create a box and add material to it.
let entity = Entity()
entity.components.set(ModelComponent( mesh: .generateBox(size: 0.4, cornerRadius: 0.05), materials: [material] ))
entity.name = "box"
// use the @Published var to position in the scene
entity.position.z = position
// add the entity as a child to the anchor
anchor.addChild(entity)
// step 3: maintain my own array of all entities to facilitate my own app’s logic
all = []
for e in anchor.children {
all.append(e)
}
}
}
Post not yet marked as solved
You cannot. You must use the publicly available versions of not just Xcode, but also of the MacOS. (Side note: I believe that beta RC candidates are the only exception to this.)
For this reason, I use this dual-boot setup:
https://support.apple.com/en-us/HT208891
and it works like a charm.
Well, as seems to be all too often and embarassingly the case - ask a question in public, and suddenly the answer reveals itself...
As it turns out I wasn't actually removing all objects in the update: closure and then replacing them - I was adding rebuilding them in my graph but not in the RealityView update: closure. Dumb oversight.
TL;DR: I was expecting the @Published values to automagically update the 3D content - much the same way that SwiftUI automatically updates 2D textfields and such. That isn't what happens in the RealityView update: closure.
So, the solution was simple:
} update: { updateContent in
updateContent.entities.removeAll()
graph.renew()
for element in graph.all {
updateContent.add(element)
}
}
where graph is a custom object that contains my RealityKit scene.
Post not yet marked as solved
Instead of Virtualization, I went with the dual-boot option. I need to run production releases of Ventura and Xcode in order to support my apps in the AppStore - but I wanted to begin work on my VisionOS app too. This setup works like a charm for me...
https://support.apple.com/en-us/HT208891
and if you're looking specifically for VisionOS sample code...
https://developer.apple.com/documentation/visionos/world
Be fine for what - development? No way is 8 GB enough. I've got 2 SwiftUI apps in the AppStore, and both were developed on a 2020 M1 MacBook Air with 16GB RAM. Working with Xcode 15 beta 2 and VisionOS simulator, it comes to a crawl. My best guess is that this is a memory issue more than a processor issue. Bottom line: the M2 Mac mini would most likely be fine, but DEFINITELY buy the most RAM you can.
Post not yet marked as solved
This worked:
@main
struct SwiftDataFlashCardSample: App {
let container: ModelContainer
init() {
let schema = Schema([Card.self])
let config = ModelConfiguration(schema: schema, cloudKitContainerIdentifier: "iCloud.org.your.name")
var contain: ModelContainer? = nil
do {
contain = try ModelContainer(for: schema, config)
} catch {
print("couldn't create ModelContainer()")
}
self.container = contain!
}
var body: some Scene {
WindowGroup {
ContentView()
}
.modelContainer(container)
}
}
and, as normal, add Capabilities iCloud.cloudKit and BackgroundModes.Remote notifications.
Post not yet marked as solved
To make it explicit, this works:
@main
struct SwiftDataFlashCardSample: App {
let container: ModelContainer
init() {
let schema = Schema([Card.self])
let config = ModelConfiguration(schema: schema, cloudKitContainerIdentifier: "iCloud.org.your.name")
var contain: ModelContainer? = nil
do {
contain = try ModelContainer(for: schema, config)
} catch {
print("couldn't create ModelContainer()")
}
self.container = contain!
}
var body: some Scene {
WindowGroup {
ContentView()
}
.modelContainer(container)
}
}
and, as normal, add Capabilities iCloud.cloudKit and BackgroundModes.Remote notifications.
Post not yet marked as solved
I transitioned from UIKit based coding to SwiftUI coding 2 years ago. SwiftUI is a completely different mindset, and it can be awkward to get SwiftUI to do UIKit kinds of things. With respect to TextField delegate methods and SwiftUI state variables - one way of thinking about it that worked for me was to gather together all of the data that you need to paint your view, and put that into either State variables or a data object. Example, instead of allowing the name, address, city and state TextFields to hold the data, it's better to define an Address struct that has those same data fields. Then, your SwiftUI app just paints the values that are in the Address struct.
Here's something else that really helped me make the transition: in UIKit programming, we tend to think of a TextField as having its own behaviors - like it holds the data for the name or address, and when the user types in that field, then the Textfield is responsible for updating it's value. In addition, it may be responsible for communicating that change to other objects in your app. In contrast, in SwiftUI, it's easiest to think about how the SwiftUI system throws away and re-creates any views whose data is no longer supporting the way the view is being painted. The data changes, then the View is discarded and re-created.
My suggestion would be to watch WWDC23's "Build an app with SwiftData" and just notice how different it is from UIKit. SwiftUI has evolved tremendously over the past 3 years, and it's now awesome expressive - but in it's own, unique way.
I didn’t realize this, but there’s an (i) button in Apple’s Shortcuts app - and when tapped it shows 2 toggles. One of which enables Spotlight, and the other enables Siri.
The solution to my question was provided via Apple’s Feedback Assistant - I just needed to (a) know about this setting, and (b) ensure the Siri toggle was turned on.
Post not yet marked as solved
Happens to me too on Xcode Version 14.2 (14C18), Watch OS 9.3.1 (20S664)
Oracle for the win! I quit messing with "brew install java" and instead downloaded the .dmg for openJKD directly from Oracle and that worked.
I've hacked my way into a solution... turns out that:
I only need to call .updateAppShortcutParameters() once
that call to .updateAppShortcutParameters() needs to include an AppShortcut(intent:, phrases:) call for each AppIntent I've written
the AppShortcutsProvider's appShortcuts:[AppShortcut] array is initialized in a way that I was not expecting... ie, you don't need []s around nor commas between array elements
so, this is what it looks like:
static var appShortcuts: [AppShortcut] {
AppShortcut(intent:IntentOne(), phrases:["phrase 1"] // no commas!
AppShortcut(intent:IntentTwo(), phrases:["phrase 2"]
}
Post not yet marked as solved
I've got 22,000 lines of SwiftUI in my app (Dvn8). I've seen this lots of times.
Most commonly, it's that your view is composed of more than 10 views, and if you'll either Group { } some of the components together, or break them out into separate functions using @ViewBuilder or AnyView, the compiler will suddenly be able to grok how to compile it all. This is something I never saw in UIKit, but it crops up a lot in SwiftUI.
Note, too, that it's not arbitrary. Once you've refactored into something the compiler can handle, it won't complain about it again.
I've also seen this crop up when I was lazy and allowed for auto type coercion - like, for example, if I've defined a var x = 0.0 but then later on attempt to access x as a CGFloat and then still later on as a Double. The compiler seems to dislike lazy coercions, so I've made a point of always being explicit in my declarations - that has seemed to minimize how often this error shows up.
Finally, if I just can't seem to find the culprit, I will go ahead and break the view into function calls that return @ViewBuilder sub-views. Almost always, this results in cleaner to read code for me, and easier to compile code for Xcode. And then I hit myself on the forehead, do my best Homer Simpson "Doh!" impersonation, and I increment iGottaRememberToDoThisMoreOften by 1.
In general, I would LOVE it if Xcode were more explicit in its errors - I've spent hours trying to track down some rather vague (although friendly!) error messages.
