It's been selective for sure. I have a macOS app that has been approved within a day. There are two apps I submit for a client both have cleared review twice in the past two weeks within 24 hours.
On the other hand I have a personal iOS app that normally doesn't take long to approve that's been waiting two weeks.
I can respect a developer who is still smitten with their craft to feel a bit anxious when the topic of LLM generated code comes up. I have a child who never grows tired of building their next game but first has to build the engine from scratch (needless to say they've built a lot of engines, not so many games). This use to frustrate me but then I realized the joy is in making a concept of a game for them. When I suggest Claude might get the job done faster I get a death glare followed by an eye roll. I get it, I've been in the industry long enough where coding is more of a means to an end and not the same novelty it once was.
More dangerous are communities who shun AI and treat every disclosure like a Scarlett letter. Generally the loudest opinions come from consumers (fan bois) and not creators. I think this will eventually drive new innovators away from these communities. These vocal naysayers have likely never experienced being a project manager, lead developer, and QA for an agent writing code. Instead they think a prompt magically creates software, but without wearing all these hats at once, you get something far worse than 'slop'. Call me crazy, but I think these multi-hat 'developers' using an agent and are dipping their toe into LLM development are going to raise the bar and leave us vim users in the dust.
Just a couple points because your opinions aren’t wrong, they’re just your lived experience.
2. There’s no magic here. There is poor documentation. The biggest trick — small views, think about what values are going to trigger a refresh. Avoid cascading view refreshes.
6. You might have missed a couple big iOS releases (iOS 7 was one to remember) where many of our apps fell over in UIKit. Swift was another ‘DOA’ for YEARS with the same issues you’re making here, each new version broke the old, but here we are in a day and age where it’s the standard.
The magic is when you use things like @State or @Published and system does bunch of things hidden behind the scenes that the developer has no idea about. Then, when issues arise, the developer is unable to debug because they have no idea how these things work and what they really do.
This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc.
Data Flow: The author claims there’s no way to know when things update. Not only does experience help here but there are profile tools that tell you when and where things are updated. This isn’t black magic. Keep Views small, be careful how you hand around data. @environment is super cool but can have a cascade effect. This was greatly improved iOS 17+ and I wouldn’t support anything older than iOS 17.
GeometryReader: Occasionally I’ll use this. It’s kind of a necessary evil when dealing with certain view complexity. It can also be a sign that you’re doing something wrong.
API Stability and performance: Apple users upgrade. There’s no reason that you should be supporting iOS 17 at this point — even iOS 18 is roughly 2%% of our user base across several apps. I’ve been using SwiftUI without major performance issues but I also don’t early optimize. I profile and fix as needed. One of the early studios I worked for wrote all our games in UIKit as prototypes, when performance tanked we’d switch to the appropriate tools (eg. OpenGL) where it was necessary — like in the core game.
I could go on but in the end just use the right tool for the job, if you’re not proficient in SwiftUI or it isn’t going to work for your cross platform project, you have a lot of other alternatives. For me though, it’s been amazing to work with. I stepped away from iOS programming for 3 - 4 years because I was burnt out using storyboards, dealing with massive view controllers, and all the boiler plate it’d take to get a view up and going in UIKit. SwiftUI roped me back in.
* Quick addition edit: Cross platform for iOS, iPad, macOS has never been good. I’ve found recent updates have made things better to the point of tolerable and it’s nothing like when we had to post-fix an ~ipad to our Nibs — There has never been a ‘glory days’ of cross platform Apple UI libraries.
I was just thinking more or less along these lines - I haven't been in mobile apps for a few years now, but back then my impression was -
SwiftUI is great for "surface level" UI, that has some basic data bindings - think a basic CRUD app, which needs some navigation, and the ability to scale across the smallest iPhone to the largest macOS screen, from touch gestures to mouse input.
If you ask anything more of it, then you need to start branching off into specific libraries / tools / frameworks (UIKit, CoreAnimation etc) - which is much easier now too, but you'll always have a bad time if you try to mix the two in a single "view" / "frame".
It's a popular controversy here much the way React is a popular controversy here: people dabble in the new idiom but don't solidly master its basics; chaos ensues and consequently resentment.
Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design.
I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more.
SwiftUI turned development, which I used to enjoy and feel good about, into a tedious trudge. I read everything I could, did the Stanford class, adopted "best practices," and really made an effort to do it right. It blows.
Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is), you wind up thrashing and performing all kinds of state-tweaking gymnastics to herd your application along through whatever tasks the user is supposed to be doing. Heaven forbid you need to walk the user through a series of steps to do or create something.
It's going to be a testing nightmare, and it suffers from every bit as much opportunity for data to get out of sync between the model and the UI as "traditional" app structure. Apple touts the "single source of truth" as gospel in SwiftUI, but you can't have that.
First of all, Swift's official position is that you should "prefer structs" over classes. But (and this is one of Swift's hokier characteristics) structs are passed by value (copied) instead of by reference. So your "single source of truth" is broken after the first function call; your data are copied all over the place.
But there's another problem with the single-source mantra: You can't just expose your core model to the UI for direct manipulation, so you have an intermediary (the so-called "viewmodel"). But that intermediary must have temporary data structures to shadow those in the core model, so the UI isn't messing directly with the model, and the user can cancel or fail when changing things without messing up the integrity of the model.
So now, once again, you don't have a "single source of truth."
The problem isn't understanding the paradigm; it's making it do useful work. Some people love to mock OO for its early and obviously cumbersome and pointless idioms, which were quickly abandoned by experienced programmers. What remains of OO is still quite useful.
I predict the same for... whatever the this mess is called. You waste so much time trying to follow the gospel of "MVVM" for no actual benefit. As I went through it, re-reading and re-digesting various pundits' viewpoints... I realized that I just had to start from scratch and build something that pays off instead of a bunch of useless ceremony.
I switched everything to classes, built managers (controllers) for the big categories of data and tasks I need to organize, and inject whatever objects I need into each view.
As for the rest of SwiftUI, its state is disgraceful. It excels at scaling UI for different screen resolutions; something that Apple neglected for waayyyyy toooo long. But there was no excuse for Apple to release a UI framework that basically didn't support the most fundamental UI paradigm of phone applications: a stack of progressive views that are programmatically manageable.
How many half-assed attempts has Apple trotted out, to do what UIKit does with ease? The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.
And yes, I know the workaround for this where you create your own struct datatype and then fill it with enums, one for each view. But come on; the fact that Apple even rolled out this ludicrous design tells you that the talented architects have left the building.
I don't want to downplay your lived developer experience, I'm not fully following all your arguments but let me just say @Environment is a great tool. We've all used singletons, even more so in UIKit seeing how unintuitive key value observation was.
It's used a few different ways in the app I'm looking at now. One is to hold a source of truth for my API data models. This way I have a cache of say User that, when it changes for whatever reason - maybe invalidating the cache (read logout) or changing a profile image - is handed around to all my Views that need User info with @Environment(\.user)
Same thing with my analytics. Something like a MixPanel is only going to be created once. It's a singleton. You pass it around in an @Environment.
NavigationStack was a problem pre-iOS 17 and even a bit of a jam in 17 -> 18 and was glad to drop that version. But passing around an enum of values makes deep linking intuitive, yes there's a bunch of boiler plate - setting up an enum I guess - but deep linking was never easy. If you're not doing deep linking then a NavigationPath is really simple to use but I assume that's not what you were talking about.
I used MVVM for about 6 months and ripped it out. There's no reason to use that pattern in SwiftUI. It was popularized by certain iOS evangelists and caught on with the newbies (myself included). Your reaction to MVVM and useless ceremony is exactly the response you should have to a code smell that doesn't belong and it was mine too.
Thanks for your observations. I don't think I've looked at NavigationStack changes since iOS 17, so I will catch up on it. But I do have NavigationPath working well enough with an enum type for each screen, which is admittedly better than the absurd endless binding of "isDisplayed" flags all the way through the stack of views.
And I will have another look at @Environment; I guess I'm thinking of @EnvironmentObject, which is a hack that I'd never choose over a singleton. My only current exposure to @Environment is as a workaround to other missing functions or properties, like this on a custom button:
> The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype.
You can use a tagged union for the "one datatype", thereby allowing your views to accept any datatype you provide in the enum. Or use NavigationPath.
Thanks. I was referring to NavigationPath. I do have it working with a bunch of custom enums. It took a while for that solution to come along; I just remember looking at NavigationPath initially and thinking it solved the whole problem, but being disappointed about its bizarrely limited design.
> The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.
You should probably read more of the documentation than looking at examples, "to create an array of one datatype" its far from the truth. NavigationPath can be use to route to more than one type https://developer.apple.com/documentation/swiftui/navigation...
Thanks, but I did read all the doc on this several times. Looking at it again, it reminds me of the fundamental problem conveyed that page: It assumes that you're using a different datatype for every view, and can thus set up NavigationDestinations for them.
But what if you're walking the user through several steps of acting upon the same datatype? Building some kind of message, for example. First add a recipient to the message. Then create and add some content to the message. Then choose delivery options for it. In each case I'm handing the Message object to the view.
Every avenue for using this thing seemed to be crippled by some blundering assumption. Until someone came up with making a special enum for every page, which is just another piece of hokey gymnastics and extra work to "trick" the UI into doing what you want.
Where you see quality crisis I see job security! Honest question, when it comes to enshittification of software quality.. have you ever had to use a Meta framework? How many times have they rewritten their mobile apps to use some architect's bespoke code pipe dream? The quality crisis has always been here, now there's just more of it.
>> It will happily recreate the same function in several different places for no reason
So do many developers. I've lost count how many times a code review had to be rejected or cleaned up because of copy and pasted code and I'm going to admit, sometimes it's just quicker to duplicate a little code and leave a comment for 'next time'.. we've all done it.
.. like this one time I had a PR and the developer created on loooong linear method, couldn't figure out how to share between targets and copied and pasted the same bad code somewhere else. Somehow it got through and when asked why this was on production the answer was 'it worked'.
>> no time for elegance
This happens, your experience in is generally your quality out. But that doesn't necessarily mean there's going to be elegance. I've worked at major product driven companies where elegance took a back seat to getting release out the door.
Having worked on an interactive novel in 2012 (NSString and attributes), low level glyphs (API deprecated) on a rogue-like, two chat apps (with markdown support for formatting) in SwiftUI, and an idle game using a mix of iOS tricks but all wrapped in SwiftUI.. I’m going to agree with how I summarized this response: skill issue.
So the author used the latest and greatest development tech to create a unique little demo in their custom language. I'm unsure your point. You know what I don't use to program with anymore? Punch cards and Borland C++. The industry has evolved for better or worse.
No idea what you think you are arguing. Are you in the wrong thread?
I said I don't get why people keep posting essentially vibe coded game clones...
I get bored checking out GitHub projects on HN that are doing absolutely nothing new and are essentially baby projects made by Claude on a weekend, and terribly architected to boot. Cluttering the feed.
No credit for the art direction and inspiration? Brogue?
Or did I miss the attribution?
* Edit: I’m not looking for the downvotes or to stir things up. I’m simply calling out that this is a small niche community we notice these things, we’re very free with our code, and copy is a compliment, but so is attribution.
The author wasn’t so much inspired the by Brogue style, but copied it directly down to the animations and ASCII.
yeah, this is a Brogue-like. I love Brogue and have been inspired by it. XsofY is not an exact clone but I've studied Brogue C source heavily when making this.
most people would name hack (1984) or the fork nethack (1987) as the successor to rogue (1980). brogue (2018) i never heard of till now but probably i aged out by then (aged out of spending many mindless i.e. repetitive hours of fun)
thanks, since i had never heard of it i had to look it up but I guess I misread it, wikipedia says the project was started in 2009, latest version in 2018. I noticed the difference in word between "project started" and "released", i'm growing numb-er, and jumped to a terribly erroneous conclusion. I have been killed by a rattlesnake.
While I can see perhaps a claim of "inspiration", when I put Brogue & this side-by-side, while artistically there is similarity, I wouldn't say "copied".
Brouge isn't the only rouge-like with LoS mechanics.
the lighting effects are very brogue and like nothing I've seen in angband, which is very very barebones ASCII by comparison. brogue-likes push into ANSI art territory with their abuse of terminal formatting.
On the other hand I have a personal iOS app that normally doesn't take long to approve that's been waiting two weeks.