7 ms·

SwiftUI errors in general are mostly unhelpful. It will go so far as to suggest a change in a thing only for the developer to find out the cause was completely

SwiftUI errors in general are mostly unhelpful. It will go so far as to suggest a change in a thing only for the developer to find out the cause was completely unrelated or even in a model in a different file. Helpful error messages for SwiftUI would go a long way

jakey_bakey 2y ago
You just gave me flashbacks to 1.0 in 2019
- ben_w 2y ago
  In my case, Metrowerks CodeWarrior student edition in the late 90s, when I was going though "C for Dummies" in highschool. Miss a semicolon, every line after but not including the one with the error. ResEdit was better in the 90s than SwiftUI was in Xcode last year. Hoping to find that standard will be re-achieved when I install the update…
  - deleted 2y ago
    [deleted]
alexashka 2y ago
Admitting SwiftUI to have been a mistake and reinvesting back into AppKit and UIKit would go a long way. In what other industry does anyone use text to create visual layouts? We still do drag and drop to design the layouts anyway, followed by re-creating the drag and drop version... using text... It's all quite maddening if you try and make sense of it.
- josv 2y ago
  iOS and macOS had a visual editor forever. Interface Builder was a really interesting take on visual layout, instantiating real objects in the interface and serializing them into nib / xib / storyboard files ready for use in your app. Most developers I know in the ecosystem tried and tried to like the visual editor, but ended up falling back to code. Why? Source code is pretty great. It’s easy to read, write, share, diff, and organize. SwiftUI has, again, a very modern and interesting take on visual editing. The code is the truth, but there’s a rich, realtime preview canvas that makes rountripping possible. For reasons, it’s unfortunately all but unusable for a lot of folks with complex Xcode projects, but it’s a very good idea. In summary: Visual layout editors and text are both pretty great. The devil’s in the details.
  - deleted 2y ago
    [deleted]
  - jwells89 2y ago
    I find that Interface Builder, while not great for editing XIBs on iOS and storyboards on either platform (it's slow and buggy in those cases), is actually still fairly pleasant when working on Mac XIBs. My go-to is pure code UIKit on iOS, but I still reach for XIBs frequently for Mac stuff. If IB's performance and stability issues could be fixed, I think its biggest problem is the near-unintelligible spaghetti XML that it generates for XIBs and storyboards, which is a huge pain for VCS and frequently cause of merge conflicts (which must be manually corrected). If they just cleaned up the XML output or switched to something more friendly to manual editing that'd help a lot.
  - raydev 2y ago
    Android Studio (before Jetpack Compose) split the difference and offered easily editable/readable XML with textual autocomplete AND a visual editor. I much preferred that after having spent years working in Xcode's Interface Builder. xibs and storyboards were also XML but IB would insert attributes that had no visual impact, move lines of XML around simply upon opening the file, or randomly change x/y values of the viewport upon opening the file, or update float values to use 15 decimal places instead of 2, and so on. Apple's insistence on making the visual editor have priority over text led to a worse developer experience as teams grew.
- cageface 2y ago
  I think a text-based, declarative rendering API is the right choice. This approach has been vindicated on the web. But the actual implementation of SwiftUI is terrible. Long compilation times, cryptic compiler error messages, bad performance, and a baked-in two-way binding observable state API that's great for code snippets and WWDC talks but makes building a coherent state model in a real app very difficult add up to a big mess.
  - deleted 2y ago
    [deleted]

jakey_bakey 2y ago

You just gave me flashbacks to 1.0 in 2019

ben_w 2y ago
In my case, Metrowerks CodeWarrior student edition in the late 90s, when I was going though "C for Dummies" in highschool. Miss a semicolon, every line after but not including the one with the error. ResEdit was better in the 90s than SwiftUI was in Xcode last year. Hoping to find that standard will be re-achieved when I install the update…
- deleted 2y ago
  [deleted]

alexashka 2y ago

Admitting SwiftUI to have been a mistake and reinvesting back into AppKit and UIKit would go a long way. In what other industry does anyone use text to create visual layouts? We still do drag and drop to design the layouts anyway, followed by re-creating the drag and drop version... using text... It's all quite maddening if you try and make sense of it.

josv 2y ago
iOS and macOS had a visual editor forever. Interface Builder was a really interesting take on visual layout, instantiating real objects in the interface and serializing them into nib / xib / storyboard files ready for use in your app. Most developers I know in the ecosystem tried and tried to like the visual editor, but ended up falling back to code. Why? Source code is pretty great. It’s easy to read, write, share, diff, and organize. SwiftUI has, again, a very modern and interesting take on visual editing. The code is the truth, but there’s a rich, realtime preview canvas that makes rountripping possible. For reasons, it’s unfortunately all but unusable for a lot of folks with complex Xcode projects, but it’s a very good idea. In summary: Visual layout editors and text are both pretty great. The devil’s in the details.
- deleted 2y ago
  [deleted]
- jwells89 2y ago
  I find that Interface Builder, while not great for editing XIBs on iOS and storyboards on either platform (it's slow and buggy in those cases), is actually still fairly pleasant when working on Mac XIBs. My go-to is pure code UIKit on iOS, but I still reach for XIBs frequently for Mac stuff. If IB's performance and stability issues could be fixed, I think its biggest problem is the near-unintelligible spaghetti XML that it generates for XIBs and storyboards, which is a huge pain for VCS and frequently cause of merge conflicts (which must be manually corrected). If they just cleaned up the XML output or switched to something more friendly to manual editing that'd help a lot.
- raydev 2y ago
  Android Studio (before Jetpack Compose) split the difference and offered easily editable/readable XML with textual autocomplete AND a visual editor. I much preferred that after having spent years working in Xcode's Interface Builder. xibs and storyboards were also XML but IB would insert attributes that had no visual impact, move lines of XML around simply upon opening the file, or randomly change x/y values of the viewport upon opening the file, or update float values to use 15 decimal places instead of 2, and so on. Apple's insistence on making the visual editor have priority over text led to a worse developer experience as teams grew.
cageface 2y ago
I think a text-based, declarative rendering API is the right choice. This approach has been vindicated on the web. But the actual implementation of SwiftUI is terrible. Long compilation times, cryptic compiler error messages, bad performance, and a baked-in two-way binding observable state API that's great for code snippets and WWDC talks but makes building a coherent state model in a real app very difficult add up to a big mess.
- deleted 2y ago
  [deleted]