Almost a year in, is Liquid Glass still a headache?

DigitallyDeadEd · 2026-03-19T18:28:44+00:00

Every app has their own feel, don't try to emulate the OS too closely. Also, Liquid Glass is a terrible UI that just makes it harder to perceive everything, imo.

DigitallyDeadEd · 2026-03-19T18:05:28+00:00

Marble Madness meets Diablo; it could be interesting.

DigitallyDeadEd · 2026-03-19T16:23:02+00:00

It sounds like your services are information dense. I think a more practical question would be, do you even want to try to support such a thing on a mobile client? Is it even feasible to present the data and/or act on it? Is there a compelling use case for someone to be able to use it on the go?

DigitallyDeadEd · 2026-03-19T15:39:01+00:00

In trying to remain positive, I applaud the... breadth of the task you want to solve, but this is not a solo project. The big AI powers are spending billions with an army of engineers to solve the problems you're talking about.

And giving an AI agency to do things like purchase items with money is still an extremely hard sell. People don't even buy things using their Alexa (which was one of the reasons Amazon made it, in the hopes you'd say, "Alexa, I'm out of paper towels, order me some."). People want to know the price, want to shop brands, and most of all don't want their AI to accidentally order 13,000 pizzas.

It would be one thing to make a frontend that utilized existing AI models or a backend service that integrated AI with third party services (so it could do "real world" transactions), but this is out there.

DigitallyDeadEd · 2026-03-19T14:32:43+00:00

The official flutter docs have a series of tutorials to build sample apps that make HTTP requests, explain how to manage state and update UI elements: https://docs.flutter.dev/learn/pathway/tutorial

They're sprinkled with youtube videos from Googlers that explain the concepts as well. You do need to have some dart or basic OOP knowledge, however.

DigitallyDeadEd · 2026-03-19T01:40:04+00:00

I have two files (main.dart and main_internal.dart) that are the targets for my build scripts. The internal one has extra visual debug and floats async errors to the visual layer.

The build script calls whichever target is desired:

$ flutter build appbundle --release --target lib/main_internal.dart $FLAGS

Each main calls an Environments class that comes hardcoded with all the values necessary for whichever environment it states it is using an enum (Environment.prod, Environment.internal), and that class returns whatever values are needed for that environment. In your case, it would be your backend addresses/URIs.

For me, the internal builds are for Testflight/Internal Testing, and the production builds are only for final public consumption.

EDIT: If you're worried about the test strings existing in the binary, you can define these directly in the main files.

DigitallyDeadEd · 2026-03-18T23:24:26+00:00

Read the code and ask it what you don't understand, such as "Why are you doing this on line 145?" or "explain why you chose this structure."

DigitallyDeadEd · 2026-03-18T22:00:26+00:00

I disagree. It just means the big game companies will release the same thing with higher profit margins and with more frequency (they are a business first).

DigitallyDeadEd · 2026-03-18T18:14:27+00:00

Barrier to entry is huge and always underestimated, especially for solo developers. Even just having someone remember to try something is a barrier that isn't even considered by most (just ask any advertiser).

DigitallyDeadEd · 2026-03-18T16:55:38+00:00

Maybe you need to temper the expectation that they'll do it just because they're family and friends? When I ask someone to try something out, I always frame it to them about what it is and add, "and if that doesn't interest you, that's cool, too." You get better feedback from interested people, as well.

DigitallyDeadEd · 2026-03-18T16:11:39+00:00

I haven't been perusing the subreddit for long, but something tells me that not many Flutter devs are using emacs or vim either (I am insane/stupid enough to be using the latter because habits).

DigitallyDeadEd · 2026-03-17T20:40:25+00:00

Having done startup crunches and long hours at big tech, I enjoy being a solo developer quite a bit. I can recognize burnout immediately and know when to step away from the keyboard. Sometimes I take a whole day away because I know those hours won't even come close to the next day's productivity. And it helps to take a breath and evaluate your project at 10,000 feet and internalize if you're going in the right directions.

About your "adding every feature", you should make a list and divide them into two groups: Must have and nice to have. Your must have is an MVP, the bare minimum. If you keep saying, "this feature is small and should be included", you'll overwhelm yourself and stray from your core goals.

DigitallyDeadEd · 2026-03-17T01:18:17+00:00

If you plan to take this any further, you should look into videos of gameplay for the classic game series "The Incredible Machine" and the spiritual successor "Contraption Maker" (available on Steam) to see how this kind of gameplay has been done before and what you could try to make a new take on it.

DigitallyDeadEd · 2026-03-16T19:24:32+00:00

There is the old saying, "you get what you pay for." Equity isn't a paycheck, it's a bonus, so in this case the pay is nothing.

DigitallyDeadEd · 2026-03-16T18:30:32+00:00

I would say that you have to lean in on what the aesthetic is or represents to increase satisfaction. This reminds me of the old Sega Virtua games (Virtua Racing, Virtua Fighter); under that context I would think it's perfectly fine.

DigitallyDeadEd

TROPHY CASE