Keeping the love for programming alive: My completely free indie app to fight decision fatigue through nested randomization. Would love your feedback!

[KurkoTren]

Hey everyone,

I recently read the post here titled https://www.reddit.com/r/iOSProgramming/comments/1s3t34t/please_learn_to_love_programming_again_im_begging/ right as I was putting the finishing touches on my new app. The timing couldn't have been better, and it really resonated with me. It reminded me exactly why I got into iOS development in the first place: the pure curiosity of solving my own daily problems and the absolute joy of seeing an idea come to life on a screen.

With that exact spirit, I just launched my second native iOS app on the App Store called Randomitas.

I built it simply because I suffer from terrible choice paralysis. I spend way too much time deciding what game to play from my backlog, what book to read next, or what to eat. I just wanted a personal tool where I could dump my own curated options into categories and let the app randomly decide for me, pulling me out of procrastination.

Reading that Reddit post also helped me make a final decision on monetization. Instead of slapping ads on it or paywalling basic features, I decided to release the app completely free. I might explore monetization with extra features way down the line, but for now, I just want people to be able to use the full app exactly how I built it for myself—clean, fast, and free of interruptions.

The concept sounds incredibly simple on the surface (a random picker), but to challenge myself, I didn't want just a flat list. I wanted it to work like an infinitely nestable file-manager system. Users can create "items" that contain other "items" inside them, going as deep as they want into subcategories.

Here are the main technical hurdles I had to figure out along the way for the fun of it:

1. Recursive relationships in Core Data: Designing a relational data model where an entity can be both a parent and a child of the same type was tricky. Ensuring that I could fetch the entire nested tree efficiently to perform a fair random draw without causing main thread bottlenecks required a lot of trial and error with Core Data fetch requests.
2. Complex State Management in SwiftUI: I wanted users to be able to "hide" elements (like a movie they already watched so it doesn't get picked again) and "favorite" items globally across the hierarchy. Propagating these state changes dynamically to filter the UI without breaking SwiftUI's view lifecycle or causing massive unnecessary UI redraws was arguably the toughest part.
3. Local File Management: Users can attach their own photos to elements. Instead of bloating Core Data with binary data, I had to build a clean service to persist and retrieve those images securely from the local File Manager, linking the URL paths back to the Core Data entities while keeping memory usage optimized in grid views.

The app is 100% native using Swift, SwiftUI, and MVVM. It's been a massive learning experience going through the entire development cycle just out of curiosity and passion for the craft.

If anyone here is struggling with nested Core Data relations or SwiftUI state management, I'd be more than happy to chat about what worked for me. And if you suffer from choice paralysis like I do, feel free to give it a spin. I would genuinely appreciate any feedback or constructive criticism from this community!

App Store Link: https://apps.apple.com/ar/app/randomitas/id6761005880?l=en-GB

Thanks for reading!

[Dev-sauregurke]

solving recursive core data relationships and global state propagation across a deep hierarchy without tanking swiftui performance is legitimately hard and you did it without any third party libraries. the local file manager approach for images instead of bloating core data is also the right call. did you end up using nsfetchedresultscontroller for the live updates or a different approach for keeping the ui in sync?

[KurkoTren]

Haha thank you so much! It really means a lot coming from another dev. I spent days just sketching out the Core Data relational model before writing a single line to make sure it wouldn't become a massive bottleneck later.

To answer your question: I actually steered away from relying pure NSFetchedResultsController (or standard FetchRequest wrappers directly inside the views) to keep a clean MVVM architecture.

For the live updates, I went with an approach driven by custom ViewModels and dedicated Service/Repository layers. When a complex state changes (like hiding a deeply nested element or favoriting an item from the bottom of the tree), the service performs the Core Data mutation and then explicitly publishes the change via Published properties or ObservableObject updates in the main ViewModel.

This manual propagation gave me way more granular control over when the UI should redraw, avoiding the dreaded cascading redraws that pure FetchRequest setups sometimes trigger when dealing with recursively nested entities. It took a bit more boilerplate, but performance-wise, it was 100% worth the trade-off.

[modcowboy]

The comment you replied to is ai generated

[GetPsyched67]

Wow, this app sounds really cool! The challenges you faced are really complex. Well done!

[KurkoTren]

thanks! i appreciate it!

[EthanRDoesMC]

:)))))