We’re working on it, lots more content on the way.

Thank you 😁

Thank you, I appreciate it!

Great question! To handle a platform specific forms of navigation (like android back navigation, or iOS gestures) you will need platform specific implementations. These implementations can be used in our shared code with KMP's "expect" and "actual" approach. I haven't made any videos on expect and actual yet, but there's a lot of good information about it here: kotlinlang.org/docs/multiplatform-expect-actual.html

@@MaximumDevelopment oh right! Thank you for the info. I will check it out.

@@MaximumDevelopment oh one more thing. Can i just use navCrontroller.popBackStack instead of handling the backpress right? like for example for splash screen.

If I understand your question correctly, yes you can. You can use the navController in your code without any need for user input. For instance, you could have the app start on a splash screen (with the home screen in the back stack), and use a coroutine to navigate back to the home page after a brief delay. There's a lot of creative ways you could approach this.

Thank you, I appreciate it!

I apologize for the delay, I've been on holiday the last week. The follow up video is being split into two parts, a conceptual overview of MVVM, and a practical demonstration in Compose Multiplatform. Both will be released as soon as possible. Thank you for your patience😁

Thank you for watching!

Not Flutter, but Compose Multiplatform.

Thank you, lots more content coming!

I'm glad to hear it, thank you!

Thank you, I appreciate it! Lots more to come!

Thank you, I appreciate it! Lots more content to come!

Thank you for the support! There's lots more to come.

Thank you! I hope so, too. KMP, especially with Compose Multiplatform, is such a great tool set. There will always be native development, but for me, being able to build apps for desktop, web, and mobile, all in Kotlin, will always be too good to pass up.

Thank you!

Great question! This could warrant its own video but here are my thoughts. For starters, we could implement our custom nav graph in its own composable, and pass our state into it. This would clean up our App component, but we would still have to deal with a large, unwieldy list of screens elsewhere. We actually have this same problem with most navigation libraries. Going beyond this, we could implement a series of nested nav graphs, breaking up our monolithic graph into smaller chunks (where navigation from certain screens would branch into different graphs). This is just one possible solution. If it were my project, I would also consider how many standalone screens could be reduced to sub-screens (removing them from the graph, and handling their visibility within their parent composable). As always, there could be many solutions to this, with differing pros and cons. I’m curious how you would approach solving this. Thank you for watching, and for your thought provoking question!

Thank you for watching, I'm glad you found it useful!

That's a great idea. For now keep an eye out for part two of my beginner's guide, coming out this week. It will cover some crucial topics like Compose lifecycle, state, and user input.

For real! The whole story of his trial and error process trying to figure out which api version the switch was running was so interesting.

Thank you!

Yes! A full length app tutorial is currently in the works.

@@MaximumDevelopment Alrighty! Looking forward to it.

Thank you, I appreciate it!

Thanks, I appreciate it!

Thank you!

Thank you! I’m glad you found it helpful.

Thank you, I'm glad you found it useful!

Glad you enjoyed it!

Thank you, I really appreciate it!

You can start learning on windows now. However, you will not be able to compile and run the iOS app without a Mac (or by using a Mac via the internet). That said, as long as you write all of your code and UI in the shared / common package, it should be nearly guaranteed to work for iOS. I’m currently saving up for a MacBook for this same reason.

Thank you! It's a great time to be a multiplatform developer. There's so many excellent options available to us.

@@MaximumDevelopment yes, love how clear you are in your explanation. So crystal clear!

I don't believe the Android Virtual Device supports eSIM implementation, mostly because of its lack of the radio hardware used to communicate to service providers. So you will need a physical device for this purpose. However, you can change your location in the virtual device (a mock GPS location), by clicking the "..." icon in the "Running Devices" window. This will bring up a pop-up with a "Location" option, which will let you select a point on a map to set as your GPS location. Best of luck!

Thanks for the support!

Thank you, I appreciate it.