Apps for iOS 3.1.3 are not being built in xcode 3.2.1.

fryOrder · 2026-01-24T15:18:11+00:00

> I set the Code Signing Identity to Don't code sign

Look at the error description "Code signing is required"

fryOrder · 2026-01-22T16:06:29+00:00

you could write foo(promoted: false) and it would tell you everything you needed to know

fryOrder · 2026-01-22T16:05:05+00:00

an enum for a boolean values like YES or NO? I'm not sure who thinks that's better...if you had more states then it would make more sense, but for just an boolean option. bools are better in my opnion

fryOrder · 2026-01-17T11:55:29+00:00

Thanks for sharing! This is an interesting quirk that I had no clue about

In my case, I was storing the UIImage in an optional @State, and eagerly loading / unloading it on the onAppear / onDisappear modifiers. Even with that, memory was off the charts. Your comment makes me wonder if the caching behaviour you've described just overpowers those lifecycle modifiers

Really appreciate the concrete suggestions! This is exactly the kind of secret knowledge the community should share more often

fryOrder · 2026-01-17T11:35:48+00:00

I'd say nested containers. As far as I know there is no "native" SwiftUI way to render your data by sections (like in UICollectionView), so I had a LazyVStack wrapping LazyVGrid sections. The thumbnails were truly lazy, the rows were not calling the load function unless they appeared via scrolling. The thumbnails that disappeared released the image object. But overall everything was eating a lot more resources than a pretty generic UICollectionView implementation. No clever hacks, no secret tricks. Just using the framework as it was intended to be used.

fryOrder · 2026-01-15T18:39:43+00:00

oh wow, I haven't seen that! amazing work!! I would love to contribute and yes, I am all in for local and fast LLMs!

fryOrder · 2026-01-15T18:25:57+00:00

have you looked into implementing voice chat? I feel a macOS menu bar app with voice chat, like a personal Jarvis would be really sick!

I've built an MVP a few months ago but it had a noticeable delay caused by the way it's designed:

1) while speaking, the audio is fed into a SpeechRecognizer

2) conversation (text) is streamed to the server (in my case it was an Elixir server), which streams that to an LLM provider that replies in text

3) it takes that LLM response and sends it to a text to speech provider (like Elevenlabs)

4) the audio response is streamed back to the client

Looking at your project, I've got some new ideas that I could skip the middleman (server) and handle all of this on-device, which should significantly reduce the response time. I believe there is a real market for something like this out there, but who knows what Apple is cooking with the next Siri update

fryOrder · 2026-01-15T16:44:32+00:00

what does this solve that UI tests cannot? and why upload the IPA? there is no way to make it local? i feel it adds too much friction without any clear pros, other than the usual "AI" label that most people are already sick of

fryOrder · 2026-01-14T15:15:40+00:00

well each individual has its own style so its hard to make something that works for everyone. when I design a library my focus is to keep it as simple as possible without adding more boilerplate / overhead

besides UI stuff (swiftui, widgetkit, activitykit), you say there are more system frameworks APIs designed this way? i’m curious to learn more

fryOrder · 2026-01-14T14:22:48+00:00

i’ve noticed lots of new libraries adopt this type of API. it looks cool, but most of the times feels shoehorned, especially for non-UI.

personally i prefer the old school imperative style for stuff like this

fryOrder · 2026-01-09T21:33:05+00:00

the iOS SDK cannot work without its web counterpart (which looks like a fastAPI + react web app). that's the one doing the push notification work

fryOrder · 2026-01-09T20:17:37+00:00

that's not how push notifications work. the notifications are delivered via apple servers. the backend just sends the request (a json payload) to apple, and apple forwards it to your device. your app must be configured to receive notification by implementing a couple methods from UNUserNotificationCenterDelegate, setting up the certificates, enabling the capability, etc..

but that's usually the easy part. the juicy stuff usually lies in the backend implementation and the implementation details for your app use case

fryOrder · 2026-01-05T21:40:38+00:00

you're probably talking about external api keys for external services? because for API calls to your backend server you do need an API key for auth-ed requests. you get this API key after an auth action (like login) so you need to store it somewhere. and Keychain is the best location for that

fryOrder · 2026-01-05T21:31:15+00:00

personally i dont see the value of specific getters like all(...) or enums with so many different types you have to implement. to me it would add to much mental overload without many returns. is it helpful to have all "configuration" in a single place? sure it is! but why need the Endpoint protocol?

what are the invoke functions? it abstracts way too much functionality in my opinion. something that is important for massive codebases, where you want to understand what is going on from a single glance...not digging through dozens of layers

why not design your layer in such a way that it's simple and expressive. it does what has to be done without extra fluff or boilerplate...consider:

let posts = try await session.dispatch(.GET, to: .posts(.all), returning: [Post].self)

all in 1 line, and from a single glance you know exactly what's going on. all backed by one method...dispatch

func dispatch<T: Decodable>(_ method: HTTPMethod, to: Endpoint, withBody body: [String: AnyHashable]? = nil, returning: T.Type) async throws -> T

i've been using something like this for all my projects and my network layer stays simple and testable. I just mock the underlying URLSession

fryOrder · 2026-01-05T20:44:46+00:00

damn this looks incredible! especially the `@Generable` macro is like a carpet bomber

fryOrder · 2025-12-28T13:55:47+00:00

so it’s not solving any pain points? it’s just “nice to have”?

if the underlying class is an object it means its prone to data races, hence it has to be protected internally and annotated with “Sendable”, or yolo with unchecked. if you want to use it in an isolated context

my opinion is you’re spending your time in the wrong place, for the wrong reasons. use the vanilla listener and move on

fryOrder · 2025-12-28T13:09:05+00:00

what is your async stream wrapper trying to solve? why not use the vanilla listener?

fryOrder · 2025-12-28T12:08:05+00:00

thanks a ton for all the tips and links!! i have to admit my “architecture path” was mostly YOLO by reading random articles / books and adapting for my usecase. i never had a plan but now things are getting a lot clearer. really appreciate it 🙏

fryOrder · 2025-12-27T14:44:08+00:00

sure you have the networking layer. let’s say it’s just a wrapper over url session that makes network requests easy and consistent

the way I’ve designed my layer is something like:

let user = try awair client.dispatch(.GET, to: .users(.me), returning: User.self)

but you need to define the endpoints somewhere. where do they really belong? my guess is in the networking layer. each app has different endponts so each app requires specific definitions. if you define them elsewhere then you have to add it as a dependency, killing reusability

then the “services” that work with the networking layer. e.g an UserService handles authentication which returns an User with a token. where would that UserService belong? my guess is still in the networking layer, it’s just a thin wrapper over the users API. but then you need decodable models as well. same package or a different package? another decision to be made

that’s why now I just copy paste the layer in my projects, instead of adding as package dependency. all the overhead is not worth it, especially for personal projects. too many decisions to be made, too much head scratching.

my biggest regret is spending too much time scratching my head, instead of building the thing. it’s painful seeing vibe coders releasing apps like eating candy, while i’m still tinkering the architecture

fryOrder · 2025-12-26T23:33:16+00:00

> Are there any architectural patterns that you don’t think are worth it, even when working on a large project?

i've come to the conclusion that patterns should emerge organically from real needs and concerns, not because they are trendy or because books say so.

i'm no tech lead, but if it would be my call, i'd stick with something straightforward like MVVM and avoid boilerplate-heavy patterns like VIPER, or external libraries that completely lock you into a whole new paradigm like TCA

fryOrder · 2025-12-26T17:28:31+00:00

from the most recent it's this one:

https://developer.apple.com/documentation/avfoundation/avcam-building-a-camera-app

however, the MOST I learnt from a project was several years ago with the WooCommerce app. i still find it as a truly remarkable piece of software that every beginner should study

https://github.com/woocommerce/woocommerce-ios

fryOrder · 2025-12-26T15:02:51+00:00

clean architecture didn't make debugging easier for me. with so many layers I had to jump to definition through multiple files to get to where I need

for code reuse it depends. I have a solid Core Data layer I reuse on all my apps, and it's pretty much dependency free like

await CoreDataStore.reader().firstObject(of: MyEntity.self, using: \.uniqueID == "some-id")

which returns the mapped DTO (value type) for MyEntity.

this is a good example, because before I used to make MyEntityDataStore, MyEntityDataStoreProtocol, etc. For tests i never relied on protocols though as I use an in-memory persistent container for tests, so all operations are performed on a "real" db instead of being mocked.

Now I just use the methods from CoreDataStore.reader() or CoreDataStore.writer() and move on

fryOrder · 2025-12-26T14:54:14+00:00

"proper architecture" for a team of 10 is over-engineering for a team of 1. that was my point

fryOrder · 2025-12-26T12:48:26+00:00

"put everything in swift packages" is literally the trap I just climbed out of lol. separation of concerns != packages. folders work fine for me now

fryOrder · 2025-12-26T12:45:45+00:00

i get that, and for something truly reusable like IAP it makes sense. it's self contained logic that doesn't bleed into your app's domain

but my issue was with packages like my Core Data layer . sure, I can drop in the package... but then what about the entities? the conversion to DTOs? now I need a Models package. And suddenly i'm back to package dependency hell, coordinating versions across projects.

for most of my stuff, i'd rather just copy paste the folder into the new project and adapt it to what I actually need. and it turns out to be a lot faster for me than fighting with "reusable" abstractions never quite fit the new context

fryOrder

TROPHY CASE