Too many classes are inaccessible

When integrating UIKit and trying to customize using existing components, too many of the components are inaccessible.

Here’s a few examples of UI Components and types that aren’t accessible when integrating via cocoapods/SPM.

  • SBUFileViewer
  • SBUUserProfileView
  • SBUFileMessageCell
  • SBUChannelSettingCell
  • Various UIImage extensions used within UIKit
  • most non-top-level classes

This makes it hard to change minor things since it requires re-implementing private classes that exist within the framework, but aren’t accessible outside of the module. For example, if one wants to override cellForRowAt to make a minor change, but still use existing components, it’s not possible since the UITableViewCell that UIKit uses is only accessible internally, not via overrides in a super class.

Since it also integrates as a static library and not source code, it’s not possible to add breakpoints and step through the UIKit code to see what’s happening.

Is there a solution to being able to make UIKit more extensible?

UIKit v2.1.13

1 Like

Hi @seths uikit offers open source code where you can change things around whatever you want. Besides that I will ping to the team to make it more extensible. Thanks for your patient

Thanks, Woo.

While we understand that it’s open-source and we can change it if the library requires forking it means it’ll be very hard to pull in new changes over time to the library. Given the library is meant to help people build, we’d side with making things being more accessible vs less. So far, we’ve had to fork and make almost all classes open/public in order to make simple changes. It’d be great if all classes were public/open by default to avoid this. I’m sure a discussion with more developers would help give a direction here.

@seths I can’t agree more with the stance you have. Thank you for the feedback!

1 Like