Post not yet marked as solved
Every place I've had to deal with wrapping text, I've had to calculate the size of the view manually and then set a frame to that size, to keep the strange truncation behavior from occuring. I'd open a bug report on it, as I truly do believe it's a bug. The Text view just doesn't seem to know how much to set it's minimum size to (always seems to be about a half line off, and rounds unpredictably... though i'm guessing, since we have no real documentation on the underlying api). Searching the forums shows some pretty creative ways to work around it, but the most reliable I've found, is to use a TextView from the UIKit (or AppKit if you're on desktop) and ask it to calculate the size for you, then set a frame with a minimum height to that.
Post not yet marked as solved
My impression is that they haven’t even really nailed down the baseline API yet. I’m sure they will release on time, but any software releases using the initial release will likely spend a lot of effort using the representables to Wrap UIKit/AppKit controllers for a good chunk of the work.
Post not yet marked as solved
Can you include the code where you actually call UserRow (and presumably load a User object from userData?
Post not yet marked as solved
In my case, it's not a problem of being buried. My application can share things just fine. It can even be opened by those shared things... unless they are in iMessage. I'm comfortable with it being a bug, given that code level support couldn't find anything amiss with my code. I appreciate the offer of the assist though.
Post not yet marked as solved
Just utilizing the container doesn't enable the sync. You have to add/request the capabilities throuigh your plist file (iCloud under capabilities, may require background too, but i'm unsure). Pretty sure you need remote notifications as well. I read on a blog somewhere a step by step to get it working, but I haven't found 'Official' instructions for anything more than the class declaration yet. I 'think' I googled NSPersistentCloudKitContainer and tutorial.. or maybe getting started.
Post not yet marked as solved
Claude31 is correct, code will help. 'Feels' like the wrong delegate function or the wrong data fed to a delegate function in play, but without code, all anyone can do is guess. The folks here are pretty good at helping out, just gotta share the code. If you're concerned, mock it up/anonymise it so it's not actual code but follows the exact same code pattern.
Post not yet marked as solved
I managed to create a similar issue for myself by opening the same project from two different versions of Xcode (10, and beta). Cleaning the build and zapping the derived folders cleared the issue for me.
Post not yet marked as solved
I spend a code level support item on the issue. It’s a bug. The response I received was a request to file a bug report, I’d suggest the same.
Post not yet marked as solved
I've been seeing the error as well on anything developed with UIKit that presents new views. I'm not sure it's not an unfinished underlying api issue with the new separation of functionality into SceneDelegate from AppDelegate, as nowhere in any of my project code do I directly call setScreen.That said, if you (or anyone else) knows the cause/solution I'd love to know as well.
Post not yet marked as solved
You could wrap them in a geometry reader, then set the width to percentages of the reader’s values. I’d offer the requested example, but I’m on the road and typing with a phone.
Post not yet marked as solved
Same issue here. From all the documentation, I believe my exported types are correct. Opening a supported file from the 'Files' app launches my app, but my app doesn't appear in activity controllers, nor can I open files 'shared' through messeges, etc.
Post not yet marked as solved
didChange has been replaced with willChange on Bindable protocols I think
Without knowing more details about what you're working on, whether or not you're using the preview pane, etc, it is difficult to offer any useful resonses. However, based on my own experiences:Live previews **** down as much system resources as a simulator, I don't use them oftenIf you interupt build processes often, sometimes the compiler process fails to die, peek at your activity monitor and check for hung processescomplex views, or views with any kind of hand coded layout logic, can take the compiler quite some time to try to resolve into a view type that is less opaque than 'some View'. Make sure extract subviews where you can as this seems to be a file scoped issue.
I get it. My experience was much the same. the XCode default when i first starting using it was under Documents, and I'd left it there since. I thought the new preview functionality was what was killing my macbook... turned out to be cloudsync and xcode not playing well with each other. I'd say that Xcode's default should likely be changed given this new 'behaviour'... but live and learn i guess.
Alignment values seem are passed down the view heirarchy, so you could try wrapping your TextField in a frame with the alignment modifier set. Though, to be brutally honest, I think TextFields as of Beta 3 are highly unpolished in general (I've been wrapping a UIKit component in lieu of using TextField).
