Skip to content

Instantly share code, notes, and snippets.

@Sajjon
Created April 19, 2020 20:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Sajjon/b7edb4cc11bcb6462f4e28dc170be245 to your computer and use it in GitHub Desktop.
Save Sajjon/b7edb4cc11bcb6462f4e28dc170be245 to your computer and use it in GitHub Desktop.
Request to Apple to create real world navigation tutorial for SwiftUI
I've been developing iOS apps for 7 years now, Swift development since 2014 and SwiftUI since last summer. The biggest challenge for any iOS developer is navigation. But at least with UIKit we had control over the navigation stack, using UINavigationController. We could implement the "Coordinator pattern" and have somewhat control. This allows for implementation of animatable replacable modal flows. Which almost every app on earth needs/uses - at least those with logins (which most have?).
Imagine this super common scenario:
Start: goto Onboarding-flow if not signed-in; else goto Main-flow.
Onboarding-flow: goto TermsOfService-flow if not acceptedToS; else (goto Tutorial-flow if not seenTutorial; else goto SignInOrSignUp)
TermsOfService-flow: // display view with link to terms & conditions and link to privacy policy. Both will open modal webview content, need to check both Toggle views, should persist this data. Goto Tutorial-flow when done
Tutorial-flow: // display multiple views steppable between
SignInOrSignUp-flow: goto SignUp-flow if selectSignUp; else if goto ForgotPassword-flow if selectForgotPassword; else goto SignUp-flow if selectSignUp; finally goto Main-flow when signedIn.
Main-flow: main flow with 4-5 tabs, each one with its own navigation stack (in UIKit typically each tabs root vc was a UINavigationController itself). One of which is a settings view, with a sign-out alternative, discarding the whole main-flow, replacing it with 'Start' (Onboarding if user needs to accept TermsOfService again, else SignInOrSignUp-flow).
Apart from this, it is also common to have a LockScreen-view with PIN, for all fin-tech apps. While also supporting deep-linking. This is very common and SUPERHARD to implement since we do not have any reference.
This is a super-duper-mega common pattern, that almost every iOS developer on earth faces, and need to implement their own solution for. You at Apple managed something which Android failed at in the beginning - providing us developers with a clear standard for UI-development, with default margins, and size classes and UI design guide lines. This has saved developers across the earth lots of time - not only saved implementation time for individual developers but also saved time for new developers joining a company, where she can be productive quite quickly since most code bases shared some code standards. This is a huge thing! But you never really provided us with a standard for navigation - which is very much trickier. Navigation is several abstraction levels higher than implementing a view. I've managed many junior iOS developers, who have all been strugling with getting navigation right.
I think almost every iOS developer in the world would LOVE it if you would provide a SwiftUI tutorial of a much more complex app than your current SwiftUI tutorials, which covers these multiple nested temporary flows of multiple views with conditional branching I've described above.
After 7 years of iteration implementing navigation solution, the one I'm most happy with is a MVVM+Coordinator based solution using RxSwift (would be using Combine for new apps of course), it is open source and if you are interested you can have a look, the app is called Zhip: https://github.com/OpenZesame/Zhip/blob/a060e99aa0293d66bc6af6f47c1b9824eac91df3/Source/Scenes/1_Main/MainCoordinator.swift#L80-L86
I think my navigation in Zhip (which allows for everything mentioned in this text), suits the declarative nature of SwiftUI very well. In Zhip it is the coordnator, not the view which makes the decision on where to go next, but it can probably be changed to the view as well. Every navigation destination is a declared `enum`, so given any navigation I know all possible destinations, all cases must be handled call site, making it declarative, expressive and clear what is happening.
If you where to provide us developers with a standardized solution for navigation in SwiftUI with comprehesive tutorials for WWDC 2020 I think all iOS developers would react the same way I reacted when you unveiled SwiftUI last summer - literally with tears of joy.
Thank you for everything Apple, SwiftUI is one of the most exciting things in my life. Please be in touch if you wanna talk about this more.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment