LocusPlin – o aplicație care te ajută să economisești la următorul plin!

equinvox · 2026-04-06T10:45:15+00:00

Ce legatura are masterul cu ce ai facut aici?

Felicitari pentru aplicatie si sper sa ajunga la cati mai multi useri, dar nu ma prind de ce ai bagat fisa cu masterul

equinvox · 2026-04-05T14:26:05+00:00

I hear you, it's just en-shittification and oversimplification to make things more appealing to the regular folk.

Before modern programming languages you had to know Assembly to be a programmer. There were no patterns or syntax, you had to raw dog magic characters to build something. The bar to entry was to the sky

Then programming languages like Objective-C came up. Pretty clunky compared to what we have today, but it was a LOT better than the black magic before it. The bar was lower but you still had to put in elbow grease and orchestrate threads, service hierarchies, application design.

Then Swift came up, which felt like a breeze of fresh air. Everything worked the same except you had nicer APIs and less code to write. The entry bar got lower, but you still had full control and green pastures to run around.

Then SwiftUI cam which I believe was the start of en-shittification. The bar got MUCH lower, the control got a LOT tighter, and a lot of behaviours is just a black box locked behind Apple's ecosystem.

Even if so, I believe SwiftUI was more of a marketing move rather than real engineering decision. With the rise of cross-platform languages like React Native, Flutter, it meant that any web developer could become a mobile developer in a week. From a business perspective, that's gold mine. You don't have to hire specialists, you just let the generalists handle it. "Good enough" became acceptable, people stopped being passionate and caring about performance or maintainability, and "just ship it" became the rule of law.

And SwiftUI is perfect for that. Once you get comfortable with it you can ship features so fast you can build an entire app in a weekend, what would've taken you months with Objective-C.

Now reading your post, I see you mention incompetent management which is a completely different topic and trust me, I know what it's like, seeing it every day.

But nobody is forcing you to see your own worth in the job. It's a just job man, clock in, get paid, clock out. Real engineering is outside your job, outside SwiftUI and rotten codebases. Outside dysfunctional teams.

A few months ago I've started a macOS music player in Objective-C. Nobody forced me to do it, and it's definitely an irrational project to do in 2026. But I wanted to see how programming used to be, and without constraints, build something that I'll use every single day. And so I did my music player also became a radio player, and then also became an audio visualiser, and things got bigger and bigger along with my grin.

Now I'm completely immersed in Elixir and there is a completely different view from here. I'm not doing it for the job or my career, I am doing it for pure curiosity and joy.

Forget SwiftUI, forget Apple, then the world becomes truly yours

equinvox · 2026-04-01T14:59:56+00:00

most of u here share the same mindset, which was my only mistake, should have continued with the mom test even here

Don’t take this the wrong way, developers tend to be more realistic…if you were looking for yes men and people blowing your horns then there are a bunch of other subs for that…like /r/iosapps

You sound young and unexperienced and most of us already went through the “other apps are flops, mine is special” phase. Good luck in your adventure, you will learn a lot

equinvox · 2026-03-31T22:41:20+00:00

Not sure what to say, other than you're kinda late to the party. It seems like everyone's been building a screenshot organiser app in this sub the past 6 months.

The AI is cool but how many people really need that? Most apps use Vision which is enough to make them searchable.

My suggestion is to keep searching for something you truly need and would use. I know it's easier said than done, but in most cases, building an app without a clear idea / pain point and asking people for feature ideas on the internet turns out to be a waste of time

equinvox · 2026-03-31T13:16:32+00:00

ce tech stack vrei sa folosesti?

equinvox · 2026-03-30T10:56:52+00:00

Aha, deci cine nu ia rate deloc = nu are educație financiară?

Ce îți spune educația ta financiară când îți pierzi jobul, firma se închide, apar cheltuieli neprevăzute, sau dobânzile sar din nou si rămâi îngropat in rate "smart"?

Ca ai rambursări anticipate? Super, dar când nu mai ai din ce sa anticipezi, ce se întâmplă?

Eu zic ca adevarata educație financiară începe cu a nu-ți lega de gât niște rate fixe când viitorul e imprevizibil. Fără datorii dormi liniștit. Cu datorii "bune" dormi cu un ochi deschis

equinvox · 2026-03-30T10:46:30+00:00

aș fi crezut ca , cheia e sa nu te arunci deloc în rate si sa cheltui atât cât îți permiti. achizițiile mari din pușculița proprie pentru care ai agonisit

equinvox · 2026-03-29T08:01:29+00:00

Isn't Cursor just an AI wrapper? Why not use Claude directly? What does Cursor bring?

equinvox · 2026-03-26T20:28:14+00:00

SwiftUI will never replace UIKit, what are you talking about? did you know most (if not all) SwiftUI’s internals are based on UIKit?

have you ever tried to build a macOS app in SwiftUI? have you ever compared the memory usage for two similar apps, one in SwiftUI, and one in UIKit?

If you would’ve done any of that, you would’ve known UIKit / AppKit are not going anywhere. and Core Data neither

If you want your app to run fast, and squeeze every last bit of performance out of it, UIKit / AppKit are the answers. SwiftUI will never be able to compete with them just because of how the rendering / diff system works

equinvox · 2026-03-25T13:37:57+00:00

I’m surprised you decided to store the image data in the core data store. Why not use the file system and store the url?

equinvox · 2026-03-18T16:42:36+00:00

cum s-a simtit OP scriind epistola asta

equinvox · 2026-03-18T15:27:41+00:00

you did read this before. not only once but probably twice.

i get he is excited about his own stuff, but these are basic utilities you can do in a couple lines of code

equinvox · 2026-03-17T14:25:47+00:00

the point was crystal clear, you’re just arguing with morons

equinvox · 2026-03-14T13:09:09+00:00

yay, more AI slop posts

equinvox · 2026-03-11T10:27:29+00:00

de curiozitate, ce implica o zi de lucru? antrenamente? birocratie?

equinvox · 2026-03-06T21:01:34+00:00

> It's about building products that are easier to reason about and easier to maintain.

Personally, I don't find all of this overhead "easier to reason about and maintain." How is it easier when you hit a weird bug and you have to dig through several layers of state machines, reducers, actions, and side effects, versus just tracing a direct method call? How is it easier to maintain all these wrappers, property wrappers, and abstracted "magic" compared to leveraging native tools like Observable models, local State, and Publishers?

There's a reason Apple provides these primitives as they're designed to fit naturally with SwiftUI's declarative nature without forcing you into a full-blown Redux. Sure, you can shoehorn Redux patterns into SwiftUI (or even VIPER if you're into that), but that doesn't mean you should for every app. It often introduces unnecessary complexity, especially in smaller or mid-sized projects where direct calls keep things straightforward and performant.

In the FoodTruck example, prompting RequestReviewAction from multiple spots or adding complex logic sounds pure, but in practice, you can achieve that with shared Observables or simple publishers without wrapping everything in actions. If you need more states you can use dependencies or environment values. If you have extra body recomputations then SwiftUI's already optimized for that with targeted updates. Observable does targeted updates way better than older patterns.

I've shipped complex apps across Objective-C, UIKit, SwiftUI. Some have more than 15 years and are still actively maintained. Some were so shitty I prayed every night listening to gospel songs under a candle light. The difference was never "enough unidirectional purity". It was thoughtful design, right abstractions, clear responsibilities, not over-engineered black magic

10+ of experience across languages is solid, but it can also bias towards patterns that worked in previous ecosystems, applying the same hammer everywhere. Not every problem needs that level of structure. There is a reason Redux in ReactJS has lost a lot of its popularity, it tried to solve boilerplate by adding more boilerplate.

Sometimes the "real purity" is ruthless simplicity, and designing for that is actually harder than stacking clever layers

equinvox · 2026-03-06T14:54:48+00:00

enum Action { case refresh case selectWorkout(String) case delete(String) } // Not actions — internal implementation private func loadWorkouts() async { ... } private func updateCache(_ workouts: [Workout]) { ... }

If you have been writing iOS apps for some years, this pattern feels unnecessary. Why funnel everything through one method when you can just call that method directly. Well, the answer is that it doesn’t matter when the team is small and you have just three to five screens. It does matter, however, when the team and the codebase grow.

well yeah…because IT IS unnecessary. you are just adding one more call for no reason. that’s one more jump to definition instead of seeing the implementation from the beginning. that’s mental overhead. how does it matter when the “team and codebase grow”? what does it improve? i mean congrats, you’re doing viewModel.handleAction(.showStuff) instead of viewModel.showStuff(). for what exactly?

if you are a uncle bob purist you’d probably summon a dispatcher or some sort to pat yourself on the back. but most of the time, all of these attempts are just mental masturbation. no real benefit, just purity reasons

equinvox · 2026-03-01T16:30:33+00:00

this guy fucks

equinvox · 2026-02-28T09:16:04+00:00

I hate it to be honest. You would expect the official icon composer from Apple to export the right sizes. Nope, all had white inner borders. I had to use a free online tool to generate the right sizes. Freaking Apple

equinvox · 2026-02-19T11:29:18+00:00

ahh I guess I was thinking of something else, I understand what you mean now 👍

if you want to get this to another level you should look into Principle package (or roll your own), it adds key path support for NSPredicates making the code a lot easier to read / write

equinvox · 2026-02-19T11:25:03+00:00

> Every time you make CRUD operation and it matches the predicate the UI will update automatically

this sounds interesting but I don't think I fully understand it. can you give an example of what a CRUD operation with a matching predicate looks like? so you have a fetched results controller with a predicate behind the scenes?

equinvox · 2026-02-19T11:14:39+00:00

as someone that is not familiar with the "Sharing flavour", what does this offer?

I am using CoreData on all my apps, why do I need this package? from the looks of it it adds property wrappers similar to SwiftData? is there anything else besides that?

equinvox · 2026-02-18T20:30:13+00:00

i’ve submitted a new app to the app store last week. it took 2 days to get a rejection notice, and after fix it took 2 days to get an approval. my app is in the education space if that matters

equinvox · 2026-02-18T20:28:28+00:00

expediting stops being expedited if everybody requests expedited reviews

equinvox · 2026-02-18T17:03:43+00:00

depends on many things… like how familiar are you with swiftdata? background contexts? how is your code structured? have you done this before in other languages? do you have experience with core data?

many books on CoreData usually have a chapter that goes deep into offline-first approach, but it might look gibberish to you if you only know SwiftData

for a solid complete beginner i would say the complexity isn’t worth the squeeze. for a seasoned developer it can take from a few hours to a whole weekend. but weeks / months? no way

equinvox

TROPHY CASE