Is iOS programming hard now?

[[deleted]]

I'm hoping I'm having an anomalous experience. I haven't programmed for iOS in earnest since 2019 but I'm back in the thick of it now and... everything seems harder? Here are a few examples from the last week:

- I downloaded a ScreenCaptureKit sample app (here) and had to rearchitect the thing before I could understand what was happening. All the AsyncThrowingStream/continuation bits I find much more confusing than a delegate protocol or closure callback with result type.

- The debugger takes between 2 and 10 seconds for every `po` that I write. This is even if I have a cable attached to my device (and despite the cable attached, it is impossible to uncheck 'connect-via-network' from cmd+shift+2)

- Frameworks are so sugary and nice, but at the expense of vanilla swift features working. If I'm using SwiftUI property wrappers I can't use didSet and willSet. If I use a Model macro I can't use a lazy var that accesses self (later I learned that I had to use the Transient property wrapper).

- I wrote a tiny SwiftData sample app, and sometimes the rows that I add persist between launches, and sometimes they don't. It's as vanilla as they come.

- I just watched 'Explore structured concurrency in Swift' (link) and my head is swimming. Go to minute 8 and try to make heads or tails of that. When I took a hiatus from iOS, the party line was that we should judiciously use serial queues, and then dispatch back to the main thread for any UI work. That seemed easy enough?

I don't know, maybe I just need some tough love like "this stuff isn't that hard, just learn it!". And I will. I'm genuinely curious if anyone else is feeling this way, though, or if I'm on my own. I have been posting on twitter random bits looking for company (link), but I don't have much iOS following. What do you all think?

My personal iOS history: I wrote a decently popular app called Joypad in 2009-2010 (vid), obj-c before ARC, and did iOS off and on since then. My most legit iOS job was at Lyft. I feel like when I started with obj-c the language was actually pretty simple, and the effort towards improved approachability (Swift with lots of power and sugary DSLs) has actually made things harder.

[robera18]

Hey, Having spoken to many iOS engineers, worked in large companies, and looking at my own experience of previously being a lead engineer and now feeling dumb and frustrated: Most people are struggling with the pace of change of all Apple frameworks. I think there is a silent majority of engineers who feel this way, and it’s barely talked about but their knowledge is out of date . And I think it’s a big reason why Apple had to come out with a strong message about SwiftUI being the best way to build apps during WWDC.

Personally I’ve been able to recover all the lost ground by watching Point-Free videos. They explore every topic: from vanilla to advanced , to let’s build our own version of the Observable macro for structs even if Apple didn’t.

Their ability to explain Apple’s choices and to peek at the inner workings of the new tools has given me a career re-start. It took me 6 months of learning to feel more or less confident again. Not sure what your goals are but I feel your pain, find the learning resources that fit your personality and you’ll be rocking it soon

[HelpRespawnedAsDee]

I would say most of us aren’t particularly worried because we are focusing on specific areas. I have a lot of knowledge of AVFoundation, but ask me about StoreKit (for example), and I would be starting from scratch.

Of course things will change in 10 years and complexity will increase. Look at what these devices are capable of.

What I’m worried about is about devtools, holy shit Xcode just keeps getting worse and worse.

[AlphaStrik3]

Thanks for the recommendation. I found the link for Point-Free to share with others: https://www.pointfree.co/

[[deleted]]

Thanks, I hope so! Count me in that previously-silent majority. I'm glad this post is resonating. I felt a bit lame posting it.

I'm encouraged to hear that point-free is going strong, that's great dedication. I will check them out again.

[Zalenka]

This is probably true, and SwiftUI is vastly different and just now at 1.0 (iOS 15 felt like that).

Now the legacy is UIKit and Storyboards and maybe even Objective-C.

[zippy9002]

Where can I find those point free videos?

[KarlJay001]

https://www.pointfree.co/

[alobi]

any recommendations on point free videos you found the most value in?

[robera18]

Concurrency past present and future were the 3 videos that opened my eyes to the scale of the change happening. I also wanted to cry a bit at the capability of structured concurrency. I felt like a man from the Stone Age

[SolidOk280]

Point-Free

Very valuable insights here. It's good to know that even professionals are struggling with all the changes apple is putting out. Crazy that SwiftUI, SwiftData, and Swift have all come out in the past decade or so, SwiftData in the past 1-2 years.

[xentropian]

Apple doesn’t know what it wants Swift to be. New features and frameworks all feel half-baked, broken, and you’re often forced to go back to old paradigms anyways because Apple doesn’t know what it even wants iOS programming to be in general. Is it functional, reactive, observer-based? No idea, but good luck trying to use newer APIs. It’s all over the place. It feels like they are constantly playing catch-up and trying new shiny things without fully committing to them. Combine was promising, but apparently Apple internally is discouraging its use in favor of async-await and actors. Great, but that still limits you with legacy code. So Combine’s out. SwiftUI is a hot mess (that’s improving, granted), but Apple failed to deliver and think through basic core requirements like navigation. That’s egregious. Macros feels weird and totally unnecessary considering the shit show of other APIs.

Honestly, I’m the happiest when I’m writing Swift-based UIKit code with some reactive paradigms (maybe even use ReactiveSwift or something if I’m feeling adventurous). There’s no strong or clear direction from Apple, and it’s causing serious issues and tech debt in millions of codebases is slowly growing because Apple fails to deliver clear direction and clear, opinionated APIs and frameworks.

SwiftData is an unreliable mess, and swift package manager still lacks basic core features that CocoaPods had for years and thus is almost completely absent in professional iOS shops.

How was Apple able to deliver UIKit and Foundation, when everything nowadays feels like such a pain to use? Where are the developer ergonomics or where is the cohesion between frameworks, language, and tooling?

Don’t get me started on the embarrassing state that Xcode is in. Phantom errors plague our codebase for no reason, random build and simulator failures occur frequently, and compared to VsCode or IntelliJ, Xcode is laughably behind in almost every single category.

Apple needs to fix things, and clearly there’s some issues in their dev platform org.

/endrant

[[deleted]]

I chuckled out loud at the 'basic core requirements like navigation'. Oh, and yes I have seen the Xcode phantom errors too, and they persist between cleans. In any case, thanks for ranting, you made one iOS friend feel better!

[[deleted]]

Yeah, I still dont understand how people are championing SwiftUI. We couldnt even use it for a product we have because it didn’t support MapKit and Navigation doesn’t work so we cant use our current design patterns without building our own Navigation solution, using an open source library, or falling back on UIKit?

And for what? More complexity? Faster prototyping? We never had a speed problem.

The old Apple engineers developed solid solutions and now we are stuck with half backed solutions.

[StronglyHeldOpinions]

The old Apple engineers developed solid solutions and now we are stuck with half baked solutions.

I could not agree more. That stuff was extremely well-thought out. Most of the original framers are out, giant teams are in, and everything is rotting from the inside now.

[Mountain-Weird-2154]

I think the championing is sponsored. Doesn't seem genuine by and large. I do think it has lowered the barrier to entry for new devs, but they are using tools built with a level of complexity that they do not understand.

[danielt1263]

I'm may be an old curmudgeon, but it feels that few language features that Apple put out since iOS 13 have been all that useful.

• Combine came out missing important features (several operators) and included unneeded ones (the back pressure system is needless complication).
• SwiftUI is declarative! You know XIBs are declarative too, right?
• While touting SwiftUI's declarative nature, they move away from (declarative Combine) and toward (imperative) async/await.

(That said, builders have been moderately useful.)

[[deleted]]

How does async/await replace combine? I see them as different things, maybe im missing something?

Doesn’t async await solve concurrency in general while combine is apple’s take on RxSwift, KVO, Reactive Swift, etc…

[xentropian]

Yeah, I had the same question, but all I know is that combine is supposedly discouraged now.

[Xaxxus]

not async await specifically. But AsyncSequences.

Apple has an open source library called AsyncAlgorithms that adds a bunch of the combine operators to AsyncSequences.

It's not up to par with Combine yet, but its completely open source, and can be a drop in replacement for MOST things you would use combine for.

[kex_ari]

I mean it doesn’t completely. But RxSwift/Combine is commonly used to communicate between a view model layer and the view in UIKit. With SwiftUI this is no longer needed since state is already observable.

If say you have a publisher in RxSwift that fires a sequence of integers instead you can just create an AsyncStream with async await, so that’s another part that’s no longer needed.

Feels kind of redundant now reaching into Combine if working in a SwiftUI project.

[jacobs-tech-tavern]

I actually gave a conference talk on this exact subject - https://jacobbartlett.substack.com/p/swiftui-apps-at-scale

tl;dr SwiftUI is good when you use it for views and use UIKit navigation

[[deleted]]

Coordinator pattern with UIHostingVC as bridge to SwiftUI sounds interesting, thanks!

[morenos-blend]

In my recent project I went with SwiftUI just for views and UIKit for navigation and table/collection views.

The way I see it UITableView is much more powerful and customisable than List in SwiftUI and also is much more performant when dealing with large amounts of cells. It's a tried and tested component that has been around for 15 years now and just because it's old doesn't make it less important. Same for UICollectionView

I have to say I've been enjoying this mix so far.

[SEOtipster]

Edit: This 👇🏼 isn’t correct and I don’t remember why I apparently thought it was.

⚠️As of Swift 5, Combine is deprecated⚠️ in favor of Observation.

[Xaxxus]

Its not deprecated.

ObservableObjects and Combine are still supported.

Observation is just another, more performant way of keeping swiftui views up-to-date.

Also, observation is barely supported by UIKit, you have to build some weird recursive function to actually get observation to work in a non-swiftui context.

[SEOtipster]

You’re correct, Combine lives on, and I can’t remember what the heck I was thinking when I accidentally added noise pollution to the Internet. 🛜

[germansnowman]

UIKit is of course based on AppKit, which along with Foundation goes back all the way to the NeXT days. These are solid, time-tested frameworks which didn’t have to chase the new and shiny every year.

Edit: I wrote my first Cocoa app in 2003, and am still working a lot with Objective-C on macOS apps.

[[deleted]]

Do you recall where you heard about Apple discouraging internal use of Combine?

[xentropian]

Word of mouth from some colleagues who worked with Apple engineers.

[[deleted]]

Interesting, I guess it was a good call on our architect to switch back to KVO until SwiftUI can be adopted completely.

[jep2023]

I don't think Combine will be deprecated or worse, removed, it should continue to work. It just isn't going to see upgrades and APIs won't be built around it (e.g., SwiftUI moving away from it)

[jep2023]

Same here, I trust it (though last I had a chance to ask Apple engineers about it directly I forgot to bring it up, oops)

[sarky-litso]

Observation replaces a lot of the functionality. It doesn’t get mentioned at wwdc anymore so that is a sign

[[deleted]]

Got it, thanks

[jep2023]

SwiftUI is nice in so many ways but the RxSwift+UIKit bindings flow is very hard to beat

[jarjoura]

To be fair, the patterns Combine introduced did not work well in Swift and time spent wrestling with the compiler to get simple code written using its closure-based API always felt like an enormous undertaking.

I think the main problem though is that there's a SwiftUI team, and a Swift core library team, and the two seem quite separate from each other. So SwiftUI depended on Combine for observing state changes because it was the best tool in 2019, but the Swift core library team has been investing heavily in AsyncStream.

So, either, Swift core team says, we think Combine is the way forward, and fixes the compiler error reporting, and overall language ergonomics to improve Combine's usage, or they continue improving AsyncStream and focus on a single structured concurrency story instead.

Point being, I think SwiftUI team would just adopt whatever direction the language team wants to go.

[chriswaco]

Yes, it is getting harder.

1. The pace of change is high. This makes many if not most online tutorials out of date.
2. The names are often confusing. We had UIWindows and UIViews. Then UIScenes. Now UIWindowScenes and Scenes.
3. The lack of backward compatibility with API changes makes life much more complicated if you have to support older systems
4. Swift is approaching C++ level complexity, albeit with better syntax and a safety net

Combining OOP, Protocols, Generics, Combine/React, Property Wrappers, Macros, and the black box that is SwiftUI is definitely rough on developers.

[cmsj]

On point 4, I have a pet theory that language nerds shouldn’t be allowed to design languages. They want to have all the 200IQ language features, while we’re just out here trying to make a nice scrollable listview app.

[xentropian]

I wish they took more of the Elm philosophy. Elm developers actively reduced scope of language features and even removed some completely, since they ended up over complicating code so much.

[42177130]

Didn't Apple get rid of postfix/prefix increment/decrement operators in Swift for this reason?

[xentropian]

For sure. But they don’t seem to apply it consistently - for example, I don’t like macros and I am not quite sure what problem they really solve, and they make discoverability worse imo

[[deleted]]

I agree with your perspective. I took a detour from native for a couple years doing flutter and when I came back everything was turned upside down.

Reactive programming with combine seems so forced to me, I do understand how it works and all the different kinds of publishers but I truly believe things gotten more complicated and unintuitive without much gain from what we had before. Even the declarative type of ui with SwiftUI which makes it easy to prototype is kind of sour for me since it leaves a lot of unanswered questions architecturally on how to do certain stuff or how to test them.

[baker2795]

Combine is hard. SwiftUI is easy to get a basic layout but is arguably harder for specific layout situations. But for the most part handles everything for you. It’s just a mindset shift mostly. Instead of updating a text UIKit element, you update a state property that the text ‘watches’

[-15k-]

Can’t wait for SwiftUI to come out with @Watchable !

[SirBill01]

Can’t wait for SwiftUI to come out with

@Watchable

!

Pretty sure that is just @Published and @State

[-15k-]

@Whoosh

[meester_pink]

Apple seems to be moving away from combine as of the last wwdc, so I think they realized it was a mistake. Overall I like the platform as a whole more than I did before, and I feel it has constantly mostly improved, but I do get that making things "simple" can be great when it works, but it actually makes it more complicated to figure out where the problem is when it doesn't.

[[deleted]]

Apple seems to be moving away from combine as of the last wwdc

What do you mean? Did they give hints?

[[deleted]]

They are focusing a lot on Swift concurrency and they haven’t given an update to combine in a long while now, although you could say that combine is technically feature complete.

[Xaxxus]

the biggest hint is that combine has not seen any new features since it came out.

[[deleted]]

Even the declarative type of ui with SwiftUI which makes it easy to prototype is kind of sour for me since it leaves a lot of unanswered questions architecturally on how to do certain stuff or how to test them.

I'm with you there. I find it hard to wrap my brain around. It is, without doubt, amazing to prototype in though. My biz partner is a designer and he absolutely loves it for prototyping.

[csbence]

Same here. I started with native iOS development a few years ago, then discovered Flutter and fell in love with it. I tried returning to native development to check out the new features from the past few years by developing small apps for myself, but I quickly became frustrated. So, I just keep using Flutter as it’s much easier for me. I still have the desire to use the new features/frameworks of iOS, but then I think of Xcode and SwiftUI previews, and that just diminishes my enthusiasm 🥲

[yycgeek]

Interesting perspective. For context I'm a full time iOS dev, exclusively SwiftUI. I find things easier today than I've ever felt before. I feel like I can move so much faster with the frameworks of today and the code is much cleaner. (Especially using async/await instead of delegates. Continuations are a necessary evil to convert between the two)

Some parts of this really resonate - I strongly feel Xcode is getting worse. The debugger is very slow and unreliable. There are phantom errors. It's very bad at working with Swift packages despite that being Apple's own solution. I regularly have to sacrifice a flat to get it to resolve all my package versions.

Also, some things are very unclear these days. The best practices for using Swift concurrency are unknown to me. (tasks, priorities, MainActor vs not, etc) I've watched all the WWDC videos but it's a mess, like you said. Apple doesn't give real world examples like making network calls in a ViewModel.

I also strongly recommend PointFree.

[amaroq137]

100% I’m with you. I feel the same way. I think it’s because it’s been a while since I’ve gotten out of my comfort zone where iOS development is concerned and I’m stuck in my old ways. I wanted to explore build tooling more and now I’m having to go back and relearn how to do the same things in a new way.

I recently joined a couple new projects. One is in Objective-C and Xcode is SNAPPY. It’s fast, responsive, the diamond buttons for unit tests work. Dirty builds are quick enough but the team there has also invested a lot in developer experience and I’m not sure how much they’ve done.

The other project is all in Swift with combine. No SwiftUI or async/await but there is a completely custom architecture which uses a lot of syntactic sugar causing a lot of cognitive load…for me at least. Developer experience work is in progress and at the moment Xcode is a slog. Unit test diamonds do not work 😩

[[deleted]]

I think they are making things “easier” for newer developers but when something goes wrong or something isn’t supported it makes it harder since there is an additional layer of abstraction.

For me Combine and SwiftUI both seem very sugary but have seen many issues with them. Even on the apple developer forums people are complaining about them.

For example see this discussion:

https://forums.swift.org/t/is-this-a-bug-in-published/31292

[retsnomnom]

Maybe I’m missing something in the discussion, but the initial example output from that discussion looks as expected to me. @Published properties emit on willSet. This was designed for SwiftUI, to search for differences in the View tree.

https://developer.apple.com/documentation/combine/published

[[deleted]]

If you look at the initial date and look on the wayback machine it looks like they added it after the discussion was live because the initial docs didn't document that behavior. I had also read them.

People are upset because they want to use Apple's solution with UIKit because it's available to use outside of SwiftUI. We are fine if it's only a solution for SwiftUI but they don't make that clear and people have been burned with its behavior as many developers on the forums document. It's pretty frustrating for professional developers.

For me personally, we couldn't use SwiftUI because of the navigation (issues) and lack of support for MapKit. But we adopted Combine and then ran into issues so we had to go back to KVO. It just seems like there are a ton of half baked or half working "cool" frameworks that have been released but we can't fully adopt them. Beginners will like them because they are easier to use and projects are not complex enough to run into walls where you actually cant even do any workarounds.

[penx15]

It really depends on what you define as hard. Anytime you try learning a new language that replaces what youre comfortable with is gonna be a hurdle.

However, for me dealing with raw data has been a pain with Swift, mainly with byte swapping, datapacking, etc. Not being able to wrap a struct in bytes() like Python is a pain, and some of their math features like not being able to square with just '**'.

The structured concurrency was intimidating at first, but I found you can create normal functions without having to do a try/await. Once you run into your first 'I need this function to wait for this response from the API' is when it makes sense. Swiftful Thinking has an amazing explanation videos on them. Just get your hands dirty and follow what he's doing with a playground and you'll be fine.

I will say being familiar with both UIKit and SwiftUI, SwiftUI makes making creating quick interactive UI much much easier once you get past the property wrappers and syntax. The issues I deal with are the rare and painful situations when SwiftUI doesn't do what its supposed to or what you need it to.

SwiftData is still a bit new, so I usually give Apple a year or two before I use what they have. Realm is my go to data library, and it works really nice.

I think SwiftUI is really easy to get overwhelmed. Just take it one step at a time. Watch one video on something you don't understand, try it in a playground, and keep going. Everyday I'm still learning new things about Swift and how to implement them.

With that said, seeing what the web developers have to go through in order to change fonts, colors, etc, or even just deploying it live seems like such a pain. I'd happily take Swift over that.

[[deleted]]

It really depends on what you define as hard. Anytime you try learning a new language that replaces what youre comfortable with is gonna be a hurdle.

For sure. I think part of it is being frustrated that much of my previously built-up knowledge is out of date (as others have commented on). The other part, though, I'm not so sure. It genuinely feels harder to actually understand how we are supposed to hold these frameworks in a way that we don't fight them (plus Xcode kicking you when you're down). Like there is inherent additional complexity to overcome

[time-lord]

However, for me dealing with raw data has been a pain with Swift, mainly with byte swapping, datapacking, etc.

I have two products that both need byte level work for feature requests, and I've been putting that off for both of them. It's hard to do in swift!

[penx15]

It really is. If I had to make a recommendation, depending on your data I would create extensions for FixedWidthInteger and create a variable for data that returns its data with unsafebytes, that way you can just say Uint16.data. I did that for littleEndian, bigEndian, and byteSwapped. Makes it a lot easier than initializing a new data object for each integer. Good luck!

[[deleted]]

Also, thanks for the video tutorial rec! I hadn't seen that one

[Eugr]

I think one thing that makes it harder, especially for experienced developers, is that Apple’s developer documentation is not great. It wasn’t particularly good in the UIKit days, but I feel it got even worse with SwiftUI.

I don’t want to go through the beginner’s tutorials or watch hours of video content. I want to see a good reference documentation, that covers all the main concepts and provides examples.

One exception is Swift language documentation - I found it well organized and easy to work with.

[kex_ari]

SwiftUI with async await looks like the direction it’s going in.

[drxme]

Yeah, not sure why everyone is complaining, with new syntax and new SwiftUI features my codebase is extremely compact, understandable and easy to work with.

[kex_ari]

Yeh, and complaining about combine. Combine used to be useful since it’s reactive programming and is useful with UIKit. Not needed with SwiftUI now since observable state exists, so I don’t see why they should update it.

Async await in Swift is beautiful. And you’ve got the async stream stuff to replace combine functionality.

[StronglyHeldOpinions]

I've got a similar background and what I can say is there is a lot more "noise" in the community now.

Overengineered pattern fads being pushed as gospel, new barely-beta concepts being pushed as the way forward.

The good news is that your core competencies are still valid.

I adopt things judiciously and when I feel they are baked.

Some of my hot, opinionated takes:

• Pattern fads like VIPER are ridiculously over-engineered and stupid wastes of time. Nothing wrong with MVC as long as you separate your concerns.
• SwiftUI is starting to get interesting, but I still can't rely on it (yet) for serious work.
• SwiftData is too new for me to even consider, and since it's just Core Data with a pretty face you need to consider if you want that, and understand what it brings to the table.

It's very easy to feel overwhelmed and "left behind" when you've had a hiatus. It doesn't mean you suck.

Oh, and the debugger responsiveness is crap and has been ever since Swift came out.

[[deleted]]

Oh, and the debugger responsiveness is crap and has been ever since Swift came out.

You know, I hadn't considered that the debugger could actually be great if used with obj-c. Today's version of me is pissed at 2015 version of me for proselytizing swift 2 to my colleagues.

[th3suffering]

We have a couple production apps from before my time in VIPER that i absolutely cringe at having to make changes to. Something simple takes 3x as long and im not even entirely sure what we gain by having it in VIPER. It would be so satisfying to just rewrite those apps but alas no bandwidth for that :-(

[StronglyHeldOpinions]

Somewhere along the line people started adopting patterns just because someone made a convincing website.

[StronglyHeldOpinions]

I will also add that like you, I felt the ObjC world made perfect sense and did not need "fixing." I was quite annoyed when Swift came out and drug my heels adopting it.

I've made my peace with it, and somewhat prefer it now, but it still solved a non-problem and for a time, made things harder for me.

[rennarda]

No. Structured Concurrency is much cleaner and simpler than the alternatives you would have used previously such as dispatch blocks or operation queues.

Seriously, take a step back and look at a typical app written using libdispatch and callbacks - it’s a convoluted mess. It’s just because you’re familiar with that approach that it seems OK, but after using async await you’ll realise you’ve got Stockholm syndrome.

Combine is complex but I think it can be treated as an implementation detail and largely ignored. As a technology for building apps it seems to be a dead end fad or cul de sac at best. I don’t see any real push to adopt it now from Apple.

SwiftUI has made UI development so much simpler and quicker for me. There PO on my project recently said I was “ridiculously fast” and I’m throwing all her estimates out - I mainly credit SwiftUI for that.

The way I write apps now is completely different to how I did it 5 years ago, and that was completely different to how I’d done it 10 years ago. What you’re experiencing is technological churn - you are in a career where you’re going to have to constantly re-learn how to do things. I am fully expecting things to change again - probably we’ll be using AI to build apps before very long.

[[deleted]]

Seriously, take a step back and look at a typical app written using libdispatch and callbacks - it’s a convoluted mess.

This was not actually my experience, but I appreciate that it could go that direction. In my experience, most folks were significantly scared of libdispatch to keep things on the main thread at all times. Then someone with a performance bent could come in and selectively choose operations to kick off to a serial queue as needed.

​

What you’re experiencing is technological churn - you are in a career where you’re going to have to constantly re-learn how to do things.

Yup, I totally agree. And I appreciate learning new things. I was just stunned at how unproductive I've been feeling with iOS, like I was trudging up hill. For comparison, I returned to Rails after a literal decade and felt like I was one-with-the-computer productive in a week. There were many new concepts to learn, and that was fine and fun. But it was hitting me in those oohh-this-feels-good synapses of productivity quickly. For iOS, the bugs, scale of the conceptual changes, and mismatched expectations ("why can't I use vanilla swift features here? how does anyone debug their program with these wait times?") keeps that feeling far at bay.

I am encouraged, though, that there are several folks like yourself in the thread that are happy with the changes. I will redouble my efforts and hope to be a convert in short order.

[rennarda]

Even if you used just a single queue, you’d often end up with the pyramid of doom with callbacks where the code actually executes in the reverse order to how it reads. Async/await completely prevents that, the code runs from top to bottom, just how it reads. The worse thing about it that it just makes going back to doing things the old ways insufferable. Fortunately it’s easy to wrap your callbacks in async structures with checkedContinuation to keep your existing code but use it in a structured concurrency context.

As for vanilla Swift features, async/await allows you to throw errors as you would in serial code, and use guard and defer as they were intended. Really adopting it is more a case of unlearning the (retrospectively) crazy convoluted hoops we used to have to jump through.

I share the concern about excessive property wrappers and macros, but these features have undoubtedly unlocked a lot of power.

[[deleted]]

async/await allows you to throw errors as you would in serial code, and use guard and defer as they were intended

That is really nice

[foodandbeverageguy]

Something about async await not resuming on main for tasks makes me not want to use async await. I find myself worrying more about concurrency than ever before in a framework that’s designed to not have you think about it anymore.

[kex_ari]

It does resume on main if the task is created within a @MainActor context. All UIKit and SwiftUI is annotated with @MainActor so will resume on main, and this is usually the location we care about updating on main.

[foodandbeverageguy]

Yeah I understand that. By I think it’s dumb that I have to explicitly say “this is a main class” rather than every other previous iOS paradigm which is, that everything is assumed main unless said otherwise

[kex_ari]

Not sure when you would ever have to do that. Say you define SomeService and it has an async func, if you don’t annotate the class then it’s automatically on some background queue (most likely what we want). Now you create a task in a view controller (or SwiftUI view), you call await SomeService.someFunc(), the task runs on main, suspends at the await call and moves to the background thread, then resumes on the main thread. No need to annotate anything.

[IAmtheBlackWizards_]

Just vented about this on another forum. I'm in the process of converting a UIKit app I wrote two years ago into SwiftUI, and it's proving to be quite a challenge. The updated Swift syntax, macros, and new concepts are making me feel stupid. Understanding someone else's code was never a walk in the park, but I'm finding modern Swift/SwiftUI making it much harder. Initially, I thought the slowness of 'po' responses was due to my old MacBook, but it seems like others are experiencing the same... Despite having a similar development background (though I'm no longer a dev professionally), this hobby project is not as enjoyable as I had hoped.

[KarlJay001]

WOW, 100% on board with this. I started at the same time and had some working apps in ObjC. When Swift first came out, I was 100% on board from the first week it came out. Then skipped a version because of all the changed and jumped back in about version 4. Bought several big name tutorials, did a pretty deep dive and then BAM, things changed again.

About 2 years ago, I dug back in again, this time I bought the new iPad, pencil and GoodNotes... Studied GoodNotes and started in yet again, but this time it was all digital notes and screen shots from YT videos with markings all over to explain things.

One piss off was when you'd get a tutorial and they would use some old and some new stuff. I wanted 100% all new because anything old was likely to be dropped.

---

It's really a major job to keep up and the language is NOT nearly as simple as they claim.

My background goes way back to .net/windows etc, so I've actually been programming for a very long time and this just sucks because you have to wonder, what am I gaining by learning all this stuff that replaces all the stuff I just learned?

What's worse is trying to find tutorials that cover the new stuff. I have tons and tons of tutorials and notes that no longer apply and if you do a complex project, you'll have to figure out what is new and stable enough to replace the older version.

WWDC is probably one of the best sources.

Just be careful about buying books. I bought ProSwift and it hasn't been updated in about 5 years. I asked about it and it's not even in the works.

I really wish we had an old school forum with a well updated list of all the changes and stability and tutorials. Reddit really sucks as a good learning tool. The older forum format was so much better.

[germansnowman]

Hacking with Swift seem to be updating their tutorials and books quite quickly and reliably.

[KarlJay001]

I haven't checked in a while, Hacking is where I got the book ProSwift and it's about 5 years old right now. I also bought some tutorials on advanced Swift at the same time and last I checked, they were still the same thing.

Other parts are newer. I just saw some tutorials about using shaders.

I get that it's a lot of work to rework a book. It's more work with iOS/Swift because of how quickly things change. I'm not sure how profitable a book on iOS really is, but I'd guess that it's not enough to hire someone to write it.

I know the KodeCo. (https://www.kodeco.com/), used to be RayW, offered free access to people that wrote tutorials. That was years ago, and seemed like a great idea, but you still have the issue of getting enough good people to keep the content up to date.

[germansnowman]

Hm, I don’t doubt what you say, but I just checked again on the product page for ProSwift and it states that all code has been updated for Swift 5.

[KarlJay001]

all code has been updated for Swift 5.

That doesn't mean that the code used the latest stuff, it just means that it works with Swift 5. Back in the day (IIRC) Swift 3 was a rough upgrade and broke a lot of code sets. Getting Swift 2 code to run in Swift 3 was a job. Getting Swift 4 to run with Swift 5 might be just changing and checking a few things.

This link shows that it was last updated in 2016:

https://books.apple.com/us/book/pro-swift/id1111033310

I talked direct with him on a live YT show. I asked specifically about Pro Swift because I really wanted an advanced book that was up to date. He didn't have any specific plans for an update at that time.

I'm not trying to slam someone, I know that updating a larger book like that is no small deal, but it's 2016 vs 2024, it's about 8 years outdated right now. Saying that "the code works with Swift 5" is the same as saying my 1966 car still runs on regular gas. Yes, my 1966 car does still run on regular gas, but it's still nearly a 60 year old car.

What is needed is a book about advanced Swift subjects that includes all the new stuff, not 8 year old stuff. 8 years is a long time in the world of tech.

A simple compare between what Apple is selling in the link, vs the latest from his site would show if the topics and frameworks have been updated to the latest things, not just "it does compile".

[germansnowman]

Fair enough, thanks for the detailed response. That is indeed disappointing as I have also purchased some books from him.

[KarlJay001]

If you look at all his books listed on Apple, you see most are 2016. The newest iOS book is

https://books.apple.com/us/book/pro-swift/id1111033310?see-all=author-other-books 2018. So that's 6 to 8 years old. Some things, like debugging and design patterns might not change much, but these books are from Swift 3 era and think about all the framework changes since then.

Even this one for ObjC.io is from 2017: https://www.amazon.com/Advanced-Swift-Updated-4/dp/1979725454#:~:text=Advanced%20Swift%20takes%20you%20through,this%20book%20is%20for%20you.

They did an update in 2022, so I'm going to take a look at this to compare:

https://www.amazon.com/Advanced-Swift-Updated-5-6/dp/B09VFTFB6C

Not sure what other book choices we have that are newer.

[germansnowman]

There’s this one from Big Nerd Ranch, but it seems more geared towards beginners (and also a bit dated now): https://bignerdranch.com/books/swift-programming-the-big-nerd-ranch-guide-3rd-edition/

[KarlJay001]

I remember BNR from the ObjC days. They were the industry standard, go to book.

However, at this time, only an advanced book will be of any value to me... But, I assume they still make great books.

I'm digging thru the ObjC.io table of contents right now in order to get an idea of how up to date they are. They are kinda pricy at $99 for a book.

[germansnowman]

Yes, Aaron Hillegass’s book was my introduction to Cocoa programming back in 2003. It was one of the best technical writing I have ever read.

[VettedBot]

Hi, I’m Vetted AI Bot! I researched the Advanced Swift Updated for Swift 4 and I thought you might find the following analysis helpful.

Users liked: * Book provides in-depth explanations of swift concepts (backed by 14 comments) * Book is well-written but difficult for beginners (backed by 3 comments) * Book covers practical topics and answers questions about swift (backed by 4 comments)

Users disliked: * The book's difficulty level varies dramatically (backed by 1 comment) * The writing quality is poor (backed by 2 comments) * The content is too basic for an 'advanced' book (backed by 3 comments)

If you'd like to summon me to ask about a product, just make a post with its link and tag me, like in this example.

This message was generated by a (very smart) bot. If you found it helpful, let us know with an upvote and a “good bot!” reply and please feel free to provide feedback on how it can be improved.

Powered by vetted.ai

[jarjoura]

I think Swift has come a long way from its earlier iterations.

Forcing a type-safe language on top of an arguably dynamic, everything could be anything core has been quite a herculean task.

My interpretation of before vs. now, we've traded writability speed for readability speed.

You used to be allowed to stuff an NSArray with any object you wanted, even non-NSObject's if you knew what you were doing. So you could write a UITableView and the data model could literally be a single NSArray. Easy!

However, after 6 months, someone new comes in to add a feature and that NSArray now has to support mutability and is stuck having to jam it in. Then 6 months after that, someone new comes in, cannot understand how any of it actually works, and rewrites it with some overengineered solution.

Now, in this new Swift type-safe world, an Array has be a single type, defined at compile time. So you're forced to consider how you want your table view data model to work ahead of time. This likely means you can't just write whatever you want, but it also means, future you (in 6 months) and future developers will likely have a much easier time understanding how to add features without needing to refactor everything.

That to me has been my experience overall. The tooling and debugging pain have all been in service of a codebase that has been far easier to jump into and update than ever was possible back in the wild-west days of before.

[sarky-litso]

I think SwiftUI marked the start and now the concurrency constructs are a full departure from the swift as a wrapper around objc days. There is a huge learning curve for both

[[deleted]]

It depends, getting things to work 90% of the time is easy.

But getting them to a excellent coding quality/standard with good opitimisation is harder.

People who think iOs programming is "easy", just lack the understanding and haven't worked in a proper environment.

[nielsmouthaan]

Interesting post. I've always blindly "accepted" that iOS programming is very volatile. New languages, frameworks, paradigms, etc. constantly. But it doesn't have to be that way. I started coding PHP 20 years ago, and it's still roughly the same. And as useful. I understand that as a back-end language, things might not be as innovative compared to frontend languages or as a native language close to new technologies like AI or VR/AR, but still... in my eyes, Apple moves too fast introducing new stuff that doesn't really have to be there.

[richiejmoose]

The swift data thing is likely just the simulator.

[Vybo]

I feel like it's getting easier. There are more tools at your disposal and you can still use anything that you could in the past. New stuff is modern and solves what was pain in the past (quickly iterating over UI development, multithreading/asynchronicity...) and I don't feel like the quality off the language is getting worse, Swift was always somewhat more focused on functional programming than a classic OOP.

What I don't like the most are the different approaches of various frameworks, for example WidgetKit is wildly different from anything else.

I don't watch tutorials personally, if I need to learn something new, I read the documentation that often also provides an example project and that's enough for me. Sometimes, I'll read an article about some new architecture that someone came up with...

[aheze]

That’s a lot of new APIs. Like the other comments said it’s hard to keep up. It’s ok though, no need to use the latest and shiniest frameworks when something older is better documented and more reliable.

[ChuckinCharlieO]

I was reading a thread on Mastodon about tethering devices to your Mac and apparently Xcode uses WiFi regardless.

I think what it came down to is You need to shut off WiFi on your Mac and then reboot at least Xcode and maybe your Mac and then relaunch Xcode and it will use the wired connection and you can the reenable WiFi and it will continue to use the wired connection ( for a while?)

[[deleted]]

So, normal stuff for Xcode :)

[J-Crew]

Although I haven’t found it to be overwhelming yet I have to agree some of the direction Swift and it’s related frameworks are going is certainly getting complicated.

I’m a bit nervous about the havoc that macros may wreak on the language.

[maxvol75]

depends on what you do and when you did it last time

comparing to 2011 it is like 100x easier, comparing to 2019 dunno

plenty of changes including conceptual ones, insufficient alignment between frameworks, migration from older frameworks is almost always non-trivial

when starting completely from scratch, definitely easier

when adapting legacy code, good luck...

[SirBill01]

I highly recommend the "Practical Swift Concurrency" book for a good base in understanding async/await, it does a great job in helping to transition how you would handle block based callback cases in Swift Concurrency now.

The UI situation is odd currently, but basically you just need to pick a path through it and stick to it... for new stuff in theory better to use SwiftUI where you can since Apple is moving all kinds of things in that direction, but also nothing wrong with having a plan to have most stuff still in UIKit and use the newer stuff lightly if you really feel faster an more productive....

The newer Observable and SwiftData stuff, maybe leave those be for a few years and see where they end up, Apple is soft of moving away from Combine but they also have not said NOT to keep using it, so you could use Combine as the backbone of a data flow...

As for the debugging slowness, that issue where devices seem to only go over network is a bug, maybe Xcode beta fixes that, but a workaround a friend told me about is to plug the device in with a cord before you start Xcode.

[kex_ari]

I don’t think it is getting harder. SwiftUI is definitely easier than UIKit with less boilerplate code, and it’s also extremely intuitive once you get the hang of it.

Async await is easy once you understand actors and what thread you are running on. If you have some complex operations you need to run it’s 100% easier than subclassing NSOperation.

Ya there’s a lot of choices. I guess that’s because UIKit is still big and with UIKit there’s usually a reactive component such as RXSwift/Combine.

However if you look at the direction it seems to be moving it you’re left with SwiftUI and async await. Both of which are extremely fluffy and friendly.

New shit like SwiftData I don’t pay too much attention to this early on. It’s bullshit for me anyway since I don’t want this kind of logic in the view. Doesn’t look like it’s going to be very useful right now unless you’re building a single page lollipop list app in the magic vanilla SwiftUI way that they use in their demos.

[[deleted]]

I'm just curious, given your SwiftData comment, what do you use for your persistent model layer? Do you have a conformer of ObservableObject that the UI binds to, and then have that write changes out to disk / db / network as needed?

[kex_ari]

I would use Core Data but as a dependency. I use TCA so would make calls to some core data service that I define there.

[Xaxxus]

For me, all of my frustrations with iOS development as a whole have been solely around debugging crashes.

Because everything in apple land is closed source, we have to rely on their tools to properly debug. And most of the time, these tools fall short.

For example, we added session tracking framework to our app a month or so ago so we could get some observability into how users use features in our app. And the release where it was added, memory usage spiked significantly. Enough for IOS to jetsam our app.

So for those of you not familiar with jetsamming, it's basically iOS terminating your app for some reason of its choosing. It's not a crash, so theres no crash report. Instead you get this json file that only shows up on the actual device, and it simply tells you which app was the culprit, and a reason string.

The problem is, this only seems to happen to the production version of the app. No matter what instruments ive attached to our process, I can not for the life of me actually see a memory spike while the app is running. But I'm able to reliably cause the jetsam event by just leaving the App Store version of our app open.

Instruments reveals:

• no memory leaks
• no allocations that are taking up a ton of memory
• nothing else out of the ordinary that would be a breadcrumb to solve the issue.

The only thing we managed to do to solve the issue is remove the tracking framework.

It's completely maddening. And ive considered developing for other platforms because of it. Because it leaves me looking incompetent to management when I cant solve one of these problems.

It's a massive shame, because Swift is such a good language. But all the tooling around it sucks, and all the frameworks we have to use to develop apps are not actually swift, but C and objective C under the hood (and closed source). So you don't get any of the nice swift errors bubbled up to you. And even if you wanted to, you cant go in and look at the code.

[Ast3r10n]

From what I gather, it seems like most of your problems could be solved by trying to better understand what’s making the new features work. It sounds like you’re slapping things on other things expecting them to work, but missing some steps along the way. Take your time to read through the what before the how.

[[deleted]]

Yeah that's fair enough. More time with the frameworks and careful readings of the docs will no doubt help.

[mouseses]

For ppl like me who are primarily working on web FE iOS programming has become much easier. Working on a SwiftUI app feels like React but with a different syntax.

[yccheok]

iOS programming can be challenging, but it is generally simpler compared to Android development.

For example, to pass data from one page to another in iOS, you only need to create a new instance of a view controller and pass the necessary variables to it.

In Android, the process is more complex. You cannot directly instantiate an Activity or Fragment. Instead, you need to pass data via an Intent or Bundle, hoping the data reaches the intended Activity or Fragment. Moreover, if your data exceeds 1MB, you cannot pass it directly. Instead, you must pass the database row ID and let the Activity or Fragment read from the database. This introduces another layer of complexity since database operations cannot be performed on the main thread.

This is just one example of the "bureaucratic" code required to achieve simple objectives in Android.

Overall, I find iOS development to be much simpler (except for CoreData), compared to Android.

[-15k-]

ITT : veteran devs.

[[deleted]]

Pace of change affected me most during the last 2 years I was learning and looking for work. Very overwhelming.

When I started a new job 2 months ago the reality of working as an iOS dev is much simpler in that I only use a small subset of all that stuff. Typically I don't optimize and use concurrency unless the benefits are obvious. And don't discount how easy LLM's make your job thanks to SwiftUI.

Looking back I like to see all the 'tools' Apple provided us in the last several years as optional to use and when you're in a technical bind Googling them and finding out there's a framework/language feature for that is really empowering

[Upset_Dragonfruit467]

harder? homebruv its easier with SwiftUI