SwiftUI :(

Avanish Rayankula
3 min readAug 28, 2021

The rapid prototyping of possibilities that this framework from Apple facilitates is amazing. However, developers may find it extremely hard to rely solely on SwiftUI for their needs.

The good thing is UIKit can be easily made to inter operate with SwiftUI via UIViewRepresentable. This is great if you want to create things like InputAccessoryView’s for your form inputs, which SwiftUI infortunately does not support off the bat.

Another thing that’s not intuitive with SwiftUI is keyboard management, resigning responder when user clicks elsewhere in the interface is kind of hard. With iOS 15.0, Apple introduced the focussed view modifier, which is great but we are currently supporting users on iOS 13.0 as well, so this kind of becomes hard to move on to use the focussed keyword for all our UI elements.

A couple of interesting hacks that we currently have in place

Hack #1: NavigationLink pops out

https://developer.apple.com/forums/thread/677333 (essentially navigation target pops out by itself, unless you add a hack to put in NavigationLink with a view and destination of EmptyView)

NOTE: Apple addressed this with iOS 15.0, but was an issue with iOS 14.5, and iOS 14.6.

Hack #2: List with complex views

Buttons used inside Complex View associated with a List Element make the entire Complex Element View clickable and not just the target fo the button.

Why this is disappointing?

As a developer who has to work with these hacks for SwiftUI bugs in place, it’s important for me to think about the following:

  • How and when we will be getting rid of these hacks, as our team drops support for older iOS versions.
  • How do we make these hacks discoverable, so that folks on the entire team are aware of their presence

How to add the hack

Method 1

Cereate an extension on the Button View itself to avoid click from being registered everywhere inside the complex element

The problem with this solution is that it’s hard for a developer to understand that there is a hack that they need to add to the control. We need to spread it. y word of mouth, internal wiki documentation about coding styles and hacks that need to be put in.

In addition when we are finally ready for deprecating the iOS version where the hack was needed, we would need to update a bunch of code that relies on the hack.

Method 2

Create a custom view with the same initialization arguments as Button called MyCustomButton.

The advantage that this mechanism offers is that we can encourage all developers to use MyCustomButton instead of Button, which will mean that the only place the hack is in place is the code inside MyCustomButton. When I used to work on a large VB6 application, this was an approach that we took to create wrappers around microsoft controls.

In the case of wrapping Microsoft VB6 controls, it made more sense becuase microsoft had stopped support for those controls and the only changes that were being made were in response to bugs being discovered by the community within those Microsoft controls. This allowed developers to not worry about the presence of those bugs, as there was a dedicated team to manage and test these controls. However, in mobile Apple is constantly adding new features and we will need to put in an excessive amount of effort to keep up with the amount of work that Apple is putting in.

My Preference

I personally lean towards Method 1, because I wish for the code to directly use Apple released controls to the extent possible. This in my opinion allows developers to find and document more hacks based on what they find in various developer forums like stackoverflow, apple developer forums etc.

NOTE: Currently our plan is to manage developer education through internal wiki’s for all SwiftUI related hacks. All hacks are currently placed in a single file and organized by the iOS version for which the hack is needed. To ensure easy discoverability, developers are encouraged to inform their peers via checkpoints when a new hack is added to the file. For developers creating features that only work on versions that are not impacted, the hack does not even need to be put in place.

--

--

Avanish Rayankula

Software developer, been working on iOS Apps for the last couple of years