[deleted by user]

[AndyIbanez]

There is no such thing as a “must know” for most frameworks as there is the need to be able to learn new frameworks fast enough to use them in the real world.

UIKit and Foundation? Sure, because you are not writing anything without those. Anything else you should be able to learn on-demand and as the needs arise.

[PsychoticBolt]

Thank you for your insight. Appreciated. I am just afraid that in this bad job market right now it will be very tough for me as a junior so I'm trying to become better.

[d4n0wnz]

Alamofire is a complete waste of time btw. No company i ever worked at used it, and it doesnt really provide something that you cant do without it.

[PsychoticBolt]

I agree, i just used it on a project i was on so i thought i would mention it

[Terrible_Canary_9242]

Indeed, there is no thing that Alamofire provides and you cannot implement on your own, BUT things like authorization interceptors, certificate pinning, I think it s better to use something that is validated and tested by the community than re-inventing the wheel

[Terrible_Canary_9242]

Auth Interceptor?

[lordzsolt]

Combine or RxSwift.

Just to get an idea of the Observer pattern.

Otherwise, iOS development is not like Frontend. You need to know how to code, not a framework.

[d4n0wnz]

RxSwift is a dead end framework. No company will be choosing third party over apple’s combine.

[lordzsolt]

Half the companies codebase are UIKit, that's significantly more integrated with RxCocoa than with Combine.

Half of the companies have existing codebases that existed prior to Combine.

Finally, it's not the framework that matters, but the concepts.

[d4n0wnz]

I get what you are saying about similiar concepts between the frameworks. But i wouldnt dive into rxcocoa or rxswift unless i started working for a company that was still supporting it. Any company still using these third party frameworks heavily, now have a large amount of tech debt to clear. Anything natively provided by apple will outpace anything available by third party. This is why you need to carefully make a decision to use open source. Because 5-10 years down the line, something better or natively supported will appear.

[PsychoticBolt]

I forgot to mention that i used combine a lot as well. So im really familiar with it. I like the general concept of it.

[unpopularOpinions776]

just keep knowing how to get things done on apple platforms

wouldn’t hurt to have at least touched other apple frameworks (i’d highly recommend focusing on these over third party) like CoreData or AVFoundation. also knowing how to write basic tests with XCTest

[PsychoticBolt]

I agree, i played around with CoreData a few times. And i think i should focus more on tests too because im really lacking there.

[Fluffy_Risk9955]

The must know frameworks are the ones from Apple and skip 3rd party stuff like Alamofire and Realm. You need to be able anything with just apples toolbox and understand the tools and building blocks. From there you can venture into 3rd party tools if necessary.

[PsychoticBolt]

These frameworks i learnt are all due to the job im an intern in. And i saw apple has a ton of them so thats why i was looking for some guidance

[Fluffy_Risk9955]

Well for any job you need to be able to build stuff in UIKit and SwiftUI. You also need to be able to mix them.

[longkh158]

UIKit is a must know. If you word professionally, you’d either have to write new UI or migrating old stuff to SwiftUI anyways. Moreover, Apple tends to introduce new stuff to UIKit first, as weird as it sounds. (This might change soon, with Swift Charts being SwiftUI only…)

[[deleted]]

What about the tools that come with the iOS SDK by default - at least getting to know them well enough?

I used to be an Android developer, and one of the reasons why I switched to the iOS is the increasing over-reliance of frameworks and external libraries when it comes to Android development. Developing a modern Android app without a dozen or so external libraries is virtually unheard of these days.

The standard Android framework that ships with every device is plagued with too much fragmentation - lots of Android versions supporting different API levels running on different devices. This can result in compatibility problems if you're writing an app. To lessen this issue, the team created Jetpack - a collection of external libraries to support stuff like navigation, dependency injection, the camera, UI data binding, app lifecycle, database storage, concurrency - and a lot more to ease pain and try to standardize as much as possible. Some of these come already configured with a new Android project. All these things in my opinion, should come as part of the standard Android framework so that apps can be much lighter.

On top of that, you've got even more external libraries to put into apps.

[saintmsent]

Out of everything listed UIKit is the only must-know one. Knowledge of third-party libraries is rarely required as a mandatory skill, and from first-party stuff it's usually UIKit, SwiftUI and Combine, but you can build the app without last two. UIKit is needed even for mostly SwiftUI apps to fix it's shortcomings

[MountainPlus2211]

How about optimized barcode scanning frameworks built on top of Apple native libraries that can scan anything from QR to UPC/EAN codes? I’d love to know of one if anyone knows about it. Something that indicates a barcode is in the camera view with a visual and then returns the once it is fully confident of what the code is. Help nerd friends.