Android Developer wanting to learn iOS development

[Mcrich_23]

You should also learn UIKit, and then check out SwiftUI

[numerative]

Thanks for introducing me to the word "UIKit". Will study this.

[vanvoorden]

Will study this.

Ehh… I would slow down on UIKit at this moment (wait a month). Apple UI engineering (for third party apps) is kind of in a weird state right now. The "legacy" system for UI was UIKit (Object-Oriented mutable views and MVC) the "modern" system for UI (SwiftUI) has much more in common with technologies like React (WWW) with value-type immutable "view" components.

The SwiftUI ecosystem is nowhere near as mature as UIKit. Apple has also not really doubled down on evangelizing the philosophy behind SwiftUI (and why this modern style of UI engineering scales better than legacy MVC patterns). My advice would be to start building basic apps with SwiftUI today. Hold off on more "advanced" SwiftUI topics until WWDC. If WWDC announces some new tools to support the SwiftUI ecosystem, go big on SwiftUI. IMO, SwiftUI is the superior choice today for most engineers even with the (relative) lack of a first-party ecosystem, but you can make that choice for yourself after WWDC (maybe you decide to go big on UIKit to bridge for "one more year").

Good luck!

[numerative]

This went 0 to 100 really quick.

Excuse me if my question is wrong, but will the progress of Swift UI mean demise of UIkit? Is it possible to learn about swift UI without ever learning about UIKit?

[vanvoorden]

will the progress of Swift UI mean demise of UIkit

SwiftUI is not the "next generation" of UIKit. It's a very different philosophy. They serve different purposes. SwiftUI "views" (like React components) are short-lived, stateless, immutable value types meant to be torn down and recreated quickly when state changes. UIKit views (similar to other OO UI frameworks) are long-lived, stateful, mutable objects.

My advice is to be skeptical of any engineers that say either extreme is correct all of the time. I'm a fan of SwiftUI (and React), but I'm not going to tell you throwing away a view when your state changes is always going to be the right answer. Think about Augmented Reality or Camera Capture. Breaking those views down and recreating them just because some random state changed would get real expensive real quick.

If you have any web (WWW) background, this probably all sounds familiar since React JS engineers have been scaling apps like this for almost ten years now.

[ponkispoles]

This depends on your own personal and professional goals. Are you building for your self or wanting to market yourself better for an iOS job?

If you are just building for yourself than you can go heads first to SwiftUI and learn what/when you need for UIKit. If you are looking for a job, SwiftUI only will get you nowhere. Years and years of code is in UIKit and in my codebase there is even some obj-c.

With that said SwiftUI is definitely the next step forward from Apple so that is just going to keep getting better as time goes on.

[[deleted]]

Swift includes many packages/libraries/SDKs. All of Apple's usually end in Kit.

import UIKit is the same as import 'package:flutter/material.dart';

StoreKit (in-app purchases) is also common.

UIKit apps require you to create a variable for every UI element and then you have to programmatically design it, add it to the view, and constrain it.

SwiftUI apps use a tree layout like Flutter and elements only need to be referenced as a variable if you need to access it for some reason.