Worse is going to be the job listing, no native iOS developer is going to touch it. It’s possible a rn + ts developer might find it an interesting challenge and maybe even have some iOS experience. I guess it all comes down to what the job qualifications are in said listing. But is your startup going to know this when/if they need to do a backfill?

But here’s the caveat to what I said. If the rest of the team you’re working in is also using the same language and maybe has some familiarity in react native it’s probably not so bad and someone can step into your shoes if necessary. Also, if your implementation is fully transparent and this is what the startup paid for, then I’m going to say more power to you, you built them what they needed and you did it your way.

* This is coming from someone doing iOS since the store opened in 2008. I've pretty much seen ALL the bad decisions at some point. There are projects I will not take no matter what the pay is.

When it comes to general software development for customers in the everyday world (phones, computers, web). I often write once for proof, iterate as product requirements becomes clearer/refined, rewrite if necessary (code smell, initial pattern was inefficient for the final outcome).

On a large project, often I’ll touch something I wrote a year ago and realize I’ve evolved the pattern or learned something new in the language/system and I’ll do a little refactor while I’m in there. Even if it’s just code organization for readability.

https://fatbobman.com/en/posts/tips-and-considerations-for-u...

Apple’s own documentation discusses this in detail and for large data sets recommends the Lazy approach. If you’re using List you’re in for some issues.

Off the top of my head, I’d consider the approach. Is it a ScrollView? A LazyVStack? What do your view redraws look like?

Anyone working with Swift Strings back in Swift 1+2 was in for some shockingly bad performance. We adopt, we adapt, and the framework matures.

But as of iOS 15+ SwiftUI is very production ready. I’ve migrated two production applications from UIKit to SwiftUI. These have active users and are available on the App Store.

Bloated? The last migration resulted in 79k new lines of code written and 181k deletions after rewriting 80% of the application.

Photos album works out of the box. If you mean camera then there are some issues depending on your use case. Beauty of SwiftUI is we can wrap UIKit views and interop allowing it to play nicely with other frameworks.

If you’re supporting applications that target the last few iOS versions it’s time to learn the new paradigm. Do yourself a favor but most of all anyone who might inherit your codebase.

I was hit with a bad oil gasket that causes the engine to burn oil. It’s so much work to replace their solution is to replace the entire engine. My solution is to keep putting oil in it. I was told by the dealer this is common over 70k miles.

The steering controls (heat, volume, cruise) stopped working pretty early on. It was well over $1k to fix, mostly labor. Apparently the connection they use is prone to failure.

Leaves me wondering if my next car will be a Toyota. Maybe if they adopted Apple CarPlay.

That being said, batteries are still good and I’ve been pretty impressed how low the maintenance has been.

iPad Pros have a very capable (and expensive) keyboard which doubles as a great stand. BLE keyboards and mice can be paired with an iPad. Wired keyboards also work.

Our security chain was so deeply embedded in every part of the OS that I was constantly trying to figure out where the failures and slow downs were coming from.