9 ms·

Shame they didn’t look at the “Fitness” app. It’s first party but requires a separate download. Probably because it’s some of the worst quality software I’ve ev

Shame they didn’t look at the “Fitness” app. It’s first party but requires a separate download. Probably because it’s some of the worst quality software I’ve ever seen. Its UI becomes desynchronized and self-inconsistent in ways I wouldn’t have believed are possible. The very fact that it exists and is capable of presenting as incoherent UI as it does is damning evidence against whatever UI framework it uses.

turdprincess 3y ago
SwiftUI exists to solve exactly this problem - the ui is declarative and state driven. However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken. Programming in UIKit is like programming in JQuery, or maybe Backbone at best. SwiftUI brings us to the modern age of react (but with less capabilities and more bugs) IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities. I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.
- jwells89 3y ago
  As a mobile dev, so far the biggest issue keeping me from adopting SwiftUI stems from its greenness and UIKit being so well fleshed out. The newness is an issue because new SwiftUI revisions ship with new iOS releases, which means that big chunks of it are gated by the oldest iOS version you support. Jetpack Compose on Android gets this more right since it’s independent of the OS, but suffers from other tradeoffs (Java ecosystem and the rest of Android dev gives me a headache sometimes). SwiftUI is also just missing various things that are present in UIKit, and so if you’re using those things it’s easier to write the whole app in UIKit instead of bridging those controls to SwiftUI. I absolutely foresee going SwiftUI exclusive but realistically that’s still a few years down the road.
  - Apocryphon 3y ago
    It's sort of dismaying that SwiftUI is regarded as a superior native choice as opposed to second-citizen cross-platform frameworks, then see examples like the macOS System Settings app. Though perhaps that is more of a case of poorly-executed Catalyst iOS to macOS porting, and poor design, than a lack of "nativeness" with SwiftUI. The framework lacking consideration for navigation until recently shows that its rollout has been half-baked, though.
    - superb_dev 3y ago
      I agree that navigation in a pure SwiftUI app is annoying, but I don't think that was short sided. It's just iterative design. At the start SwiftUI was something you could add to an existing UI/AppKit project, so individual parts could be rewritten. They've been building on top of that since. Refining the api and slowly letting you write more and more with just SwiftUI
      - plagiarist 3y ago
        The implementation seems to encourage that "leaf" views have to be aware of parent views, or what context they're in. I used to work with a guy who'd always say, "maybe I'm holding it wrong," that's how I feel about the navigation in SwiftUI. Maybe I need to see a clean example to get it.
    - jwells89 3y ago
      The problems with the macOS settings app have just as much or more to do with its design as they do with SwiftUI. If they had instead built the redesign with AppKit it’d feel a bit smoother in some areas but would be just as flawed. Just making it more traditionally Mac-like would go a long way.
      - Apocryphon 3y ago
        I've heard a lot of disgruntlement from macOS developers about SwiftUI. I wonder if the framework has an inherent bias for iOS and maybe iPadOS? Again, it's crazy that after years of disparagement of kludgy cross-platform frameworks (albeit more from the fans than the company itself), Apple basically went ahead and built their own, with fewer supported frameworks than the third-party alternatives.
- tambourine_man 3y ago
  I’m a web developer and I hate React and TypeScript. I love jQuery.
  - brailsafe 3y ago
    It's hard to make client-side webapps, using a procedural programming paradigm just makes it harder than it needs to be, but using jQuery for anything else is exactly why it got popular.
    - tambourine_man 3y ago
      What’s hard is making up languages that compile down to JS/HTML/CSS, debugging through source maps, having 50k dependencies just to create a view to choose between 3 shirt sizes and 2 colors. What’s not that hard is managing a bit of state and writing sensible CSS to make it reusable.
      - shirogane86x 3y ago
        As someone who worked in a decently sized company working on a software product written with TS/HTML/SCSS (at least we had those) and jQuery: no, absolutely not. as the apps get big, state becomes a mess, fully reusing code is very hard, making anything even slightly reactive becomes not only a lot of code, but a jumbled mess of mutability, usually copy pasted from somewhere else. I will take any other type of app over that - I don't care if it's angular, vue, react, next, whatever. So i contend that not only is "managing a bit of state and writing sensible CSS to make it reusable" very hard, I haven't even seen it done ever, at least in my personal experience of the code I touched
        brailsafe 3y ago
        Yes, exactly. The requirements of most functional production applications on the web already have so many complicated bits to get right, people shouldn't be burning their energy on what end up being inane details like synchronization UI with state. At a much much smaller scale however, jQuery and CSS or in many cases just HTML and CSS will do just fine. Knowing which approach to take is the mark of someone with some level of experience above junior.
- meindnoch 3y ago
  >brings us to the modern age of react Thanks, I vomited a bit into my mouth.
- vor_ 3y ago
  > IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Resistance to SwiftUI has more to do with the incompleteness and bugginess of the framework than a refusal to embrace modern paradigms. A common impression of SwiftUI is that it makes hard things easy and easy things hard.
dpkonofa 3y ago
What inconsistencies are you referring to? I don't think I've had any desyncs or inconsistencies in the Fitness app.
- explaininjs 3y ago
  The “Sharing” tab is particularly atrocious, the circles in each list widget frequently do not match the rest of the data in the widget (or indeed seemingly any data at all). This is resolved by scrolling the particular broken widgets out of view then back in. It would seem somewhere in the pipeline the widgets are templates/virtualized and the logic to fill a given widget with the right data goes completely bonkers at times and needs to be reset by hiding it then showing it again. Besides that, many of the “Awards” views frequently show incorrect/ancient/impossible data. For instance I recently saw “You will earn this when you reach you move goal 100 times. You’ve reached your move goal 102 times so far.” with the seat not unlocked. The number sounds only slightly off, but keep in mind that’s 3 days of stale data. I saw similar bugs with the “Perfect Week” award and “Longest Move Steak” one. (At one point I had a move streak of 21 days, the badge said it was 14 days, and the perfect week badge was still not unlocked. You’ll note any 14 day period must contain a full monday-sunday period, not to mention in reality my streak was 3 weeks). The daily summary view is admittedly fine. Though the refresh interval is something like 15 minutes which is absurd for a pedometer. Not sure if the app or the API is to blame there. Sight aside, but not really. The settings/Account modal is impossible to discover, and when you do 5/6 menu options have a reasonable flow where you can click to go into the detail view, then hit back to return to the main modal (or exit entirely). Except for the “Change Move Goal” detail, which can only be exited entirely, it is impossible to return to the Account modal directly. I’ve never used “Fitness+”, their paid offering, but I assume the quality there would be about as bad as everywhere else.
  - steve1977 3y ago
    Health app is not much better unfortunately. My weekly and monthly sleep averages look about right. The 6 month average is off by about 1.5 hours. Funnily enough, it’s been off by that amount consistently for at least half a year now.

turdprincess 3y ago

SwiftUI exists to solve exactly this problem - the ui is declarative and state driven. However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken. Programming in UIKit is like programming in JQuery, or maybe Backbone at best. SwiftUI brings us to the modern age of react (but with less capabilities and more bugs) IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities. I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.

jwells89 3y ago
As a mobile dev, so far the biggest issue keeping me from adopting SwiftUI stems from its greenness and UIKit being so well fleshed out. The newness is an issue because new SwiftUI revisions ship with new iOS releases, which means that big chunks of it are gated by the oldest iOS version you support. Jetpack Compose on Android gets this more right since it’s independent of the OS, but suffers from other tradeoffs (Java ecosystem and the rest of Android dev gives me a headache sometimes). SwiftUI is also just missing various things that are present in UIKit, and so if you’re using those things it’s easier to write the whole app in UIKit instead of bridging those controls to SwiftUI. I absolutely foresee going SwiftUI exclusive but realistically that’s still a few years down the road.
- Apocryphon 3y ago
  It's sort of dismaying that SwiftUI is regarded as a superior native choice as opposed to second-citizen cross-platform frameworks, then see examples like the macOS System Settings app. Though perhaps that is more of a case of poorly-executed Catalyst iOS to macOS porting, and poor design, than a lack of "nativeness" with SwiftUI. The framework lacking consideration for navigation until recently shows that its rollout has been half-baked, though.
  - superb_dev 3y ago
    I agree that navigation in a pure SwiftUI app is annoying, but I don't think that was short sided. It's just iterative design. At the start SwiftUI was something you could add to an existing UI/AppKit project, so individual parts could be rewritten. They've been building on top of that since. Refining the api and slowly letting you write more and more with just SwiftUI
    - plagiarist 3y ago
      The implementation seems to encourage that "leaf" views have to be aware of parent views, or what context they're in. I used to work with a guy who'd always say, "maybe I'm holding it wrong," that's how I feel about the navigation in SwiftUI. Maybe I need to see a clean example to get it.
  - jwells89 3y ago
    The problems with the macOS settings app have just as much or more to do with its design as they do with SwiftUI. If they had instead built the redesign with AppKit it’d feel a bit smoother in some areas but would be just as flawed. Just making it more traditionally Mac-like would go a long way.
    - Apocryphon 3y ago
      I've heard a lot of disgruntlement from macOS developers about SwiftUI. I wonder if the framework has an inherent bias for iOS and maybe iPadOS? Again, it's crazy that after years of disparagement of kludgy cross-platform frameworks (albeit more from the fans than the company itself), Apple basically went ahead and built their own, with fewer supported frameworks than the third-party alternatives.
tambourine_man 3y ago
I’m a web developer and I hate React and TypeScript. I love jQuery.
- brailsafe 3y ago
  It's hard to make client-side webapps, using a procedural programming paradigm just makes it harder than it needs to be, but using jQuery for anything else is exactly why it got popular.
  - tambourine_man 3y ago
    What’s hard is making up languages that compile down to JS/HTML/CSS, debugging through source maps, having 50k dependencies just to create a view to choose between 3 shirt sizes and 2 colors. What’s not that hard is managing a bit of state and writing sensible CSS to make it reusable.
    - shirogane86x 3y ago
      As someone who worked in a decently sized company working on a software product written with TS/HTML/SCSS (at least we had those) and jQuery: no, absolutely not. as the apps get big, state becomes a mess, fully reusing code is very hard, making anything even slightly reactive becomes not only a lot of code, but a jumbled mess of mutability, usually copy pasted from somewhere else. I will take any other type of app over that - I don't care if it's angular, vue, react, next, whatever. So i contend that not only is "managing a bit of state and writing sensible CSS to make it reusable" very hard, I haven't even seen it done ever, at least in my personal experience of the code I touched
      - brailsafe 3y ago
        Yes, exactly. The requirements of most functional production applications on the web already have so many complicated bits to get right, people shouldn't be burning their energy on what end up being inane details like synchronization UI with state. At a much much smaller scale however, jQuery and CSS or in many cases just HTML and CSS will do just fine. Knowing which approach to take is the mark of someone with some level of experience above junior.
meindnoch 3y ago
>brings us to the modern age of react Thanks, I vomited a bit into my mouth.
vor_ 3y ago
> IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Resistance to SwiftUI has more to do with the incompleteness and bugginess of the framework than a refusal to embrace modern paradigms. A common impression of SwiftUI is that it makes hard things easy and easy things hard.

dpkonofa 3y ago

What inconsistencies are you referring to? I don't think I've had any desyncs or inconsistencies in the Fitness app.

explaininjs 3y ago
The “Sharing” tab is particularly atrocious, the circles in each list widget frequently do not match the rest of the data in the widget (or indeed seemingly any data at all). This is resolved by scrolling the particular broken widgets out of view then back in. It would seem somewhere in the pipeline the widgets are templates/virtualized and the logic to fill a given widget with the right data goes completely bonkers at times and needs to be reset by hiding it then showing it again. Besides that, many of the “Awards” views frequently show incorrect/ancient/impossible data. For instance I recently saw “You will earn this when you reach you move goal 100 times. You’ve reached your move goal 102 times so far.” with the seat not unlocked. The number sounds only slightly off, but keep in mind that’s 3 days of stale data. I saw similar bugs with the “Perfect Week” award and “Longest Move Steak” one. (At one point I had a move streak of 21 days, the badge said it was 14 days, and the perfect week badge was still not unlocked. You’ll note any 14 day period must contain a full monday-sunday period, not to mention in reality my streak was 3 weeks). The daily summary view is admittedly fine. Though the refresh interval is something like 15 minutes which is absurd for a pedometer. Not sure if the app or the API is to blame there. Sight aside, but not really. The settings/Account modal is impossible to discover, and when you do 5/6 menu options have a reasonable flow where you can click to go into the detail view, then hit back to return to the main modal (or exit entirely). Except for the “Change Move Goal” detail, which can only be exited entirely, it is impossible to return to the Account modal directly. I’ve never used “Fitness+”, their paid offering, but I assume the quality there would be about as bad as everywhere else.
- steve1977 3y ago
  Health app is not much better unfortunately. My weekly and monthly sleep averages look about right. The 6 month average is off by about 1.5 hours. Funnily enough, it’s been off by that amount consistently for at least half a year now.